Windows Postgres Deployment Installer

An anonymized Windows installer project derived from a real-world deployment script for PostgreSQL and desktop application rollout.

Goal

Create a public-safe version of the original installer by removing client-identifying details while preserving the deployment architecture, idempotent behavior, and operational patterns.

Design Intent

This project is intentionally Windows-centered.

It is designed primarily for:

• Windows 10
• Windows 11
• operator-led workstation and small-server deployments
• environments where fast, repeatable setup matters more than full infrastructure automation

The original operational problem was not theoretical elegance. It was time, variance, and recovery.

Manual installation and configuration routinely took around 2 hours. The automation pattern behind this project reduced that to less than 7 minutes in the original environment by standardizing the sequence, reducing human repetition, and making reruns safer.

The design priorities are:

• agility
• standardization
• repeatability
• operator assistance
• strong fallbacks
• human review after automation

This installer is not meant to replace judgment. It is meant to help a human operator complete the heavy, repetitive, error-prone parts quickly, then review the resulting machine state and make environment-specific decisions.

Operating Philosophy

This project assumes a human is still in the loop.

The automation handles the bulk of:

• PostgreSQL bootstrap
• service registration
• config deployment
• role synchronization
• database creation
• restore orchestration
• firewall setup
• share creation

But it intentionally still expects a human to:

• provide environment-specific configuration
• verify the final paths, ports, and access rules
• review restore success and logs
• validate application-specific behavior after installation
• decide whether local defaults and network rules are appropriate for the site

The goal is assisted standardization, not blind zero-touch deployment.

Why PowerShell And Why This Shape

This repository keeps a pragmatic PowerShell-first design because the target environment is Windows administration, not container-native orchestration.

The script shape reflects real deployment constraints:

• inconsistent starting machine state
• need for reruns after partial installs
• need for local service registration
• need for filesystem, registry, firewall, and SMB operations in one flow
• environments where a technician may be working interactively on the machine

The code favors explicit operational steps and fallbacks over abstraction for abstraction's sake.

Current Status

This repository contains an anonymized, public-safe baseline:

• scripts/installer.ps1
• scripts/uninstall.ps1
• templates/postgresql.conf.txt
• templates/pg_hba.conf.txt

Intended Outcomes

• Generic application naming
• Generic network, share, and firewall configuration
• Generic PostgreSQL setup flow
• Public-safe documentation and sample templates
• No client secrets, internal hosts, or proprietary binaries

Current Baseline

The current scripts are a sanitized, publishable Windows deployment baseline focused on PostgreSQL bootstrap and operator-assisted standardization.

Included today:

• generic config block for install path, PostgreSQL path, share name, and firewall names
• PostgreSQL config templating and patching
• PostgreSQL ZIP bootstrap with initdb, service registration, and startup
• self-signed PostgreSQL SSL setup
• PostgreSQL role creation and update
• database creation
• optional restore workflow with temporary performance acceleration
• final SQL validation
• share and firewall setup routines
• matching uninstall scaffold

Not included in this public version:

• download pipeline and staged artifact acquisition
• desktop shortcut deployment
• auxiliary dependency installation
• detailed system telemetry and reporting

Usage

Create a local config.ps1 from:

• config.example.ps1

Then edit your private values there and run:

• scripts/installer.ps1
• scripts/uninstall.ps1

Provide a PostgreSQL binaries ZIP at the path configured in config.ps1 and run the scripts in an elevated PowerShell session.

Recommended first pass:

1. Copy config.example.ps1 to config.ps1.
2. Review every path, port, service name, restore option, firewall rule, and share setting.
3. Run on a disposable VM or non-production workstation first.
4. Keep independent backups before restore or uninstall operations.
5. Review the final PostgreSQL service, logs, firewall rules, and database state manually.

For operational safety guidance, see SECURITY.md.

Config Notes

The installer now supports config entries for:

• install root
• database install and data paths
• database service name
• database port
• database listen addresses
• database max connections
• database owner and superuser
• optional LAN CIDR allow-list
• restore file path
• restore enable/disable behavior
• restore parallelism
• validation query
• firewall rule names
• share name

The default example config is intentionally conservative:

• listen_addresses = 'localhost'
• no LAN CIDRs enabled by default
• SMB share creation disabled by default
• share access must be explicitly configured when enabled

Safety Note

The installer performs real filesystem, firewall, SMB share, service, and registry operations. Use a test machine and keep config.ps1 private.

The uninstaller is destructive after confirmation: it removes configured PostgreSQL service metadata, firewall rules, SMB share, install directories, and application files.

Supportability Notes

This project is optimized for speed and repeatability, but not at the expense of operator review.

It includes fallbacks and rerun-friendly behavior, but it should still be treated as an assisted deployment tool. The correct operating model is:

1. prepare private configuration
2. run the installer on a test or target Windows machine
3. review logs and final machine state
4. validate the database and application manually
5. adjust environment-specific settings as needed

---

Public Release Checklist

• PowerShell parser checks pass for installer and uninstaller.
• README and SECURITY.md describe destructive/admin operations clearly.
• config.example.ps1 remains generic and conservative.
• No real backup files, PostgreSQL ZIPs, private configs, logs, customer paths, or proprietary binaries are committed.
• Release notes state whether validation was static-only or included a live disposable-VM install.