Azure Secure Web Application – Private PostgreSQL & Cloud Infrastructure

The custom domain points to Azure Front Door, which terminates HTTPS with an automatically issued and renewed managed certificate. Routes send API requests, such as those under /api, to the App Service origin and all other requests to the Static Web Apps origin, so the frontend and API share one domain and no cross-origin configuration is needed in the browser. A web application firewall policy can be attached to filter malicious traffic at the edge.

The single-page application is built and published to Azure Static Web Apps, which serves static assets from globally distributed locations. Each deployment replaces the site atomically, so users never see a partially updated version, and preview environments can be created for pull requests.

The API runs on Azure App Service on Linux in a managed App Service plan. It scales up to larger instances or out to multiple instances from the Azure portal, with scale-out requiring no downtime. Access restrictions on the App Service allow traffic only from the Azure Front Door service tag and verify the X-Azure-FDID header, so the API cannot be called directly on its platform hostname.

An Azure virtual network contains separate subnets for the application and the database. The App Service uses regional virtual network integration to send its outbound traffic into the application subnet, which allows it to reach the database privately. Network security groups on each subnet act as firewalls; the database subnet allows only the PostgreSQL port (5432) from the application subnet and blocks everything else.

Azure Database for PostgreSQL Flexible Server is deployed with private access in a delegated subnet, with no public endpoint, and resolved through a private DNS zone. Data is encrypted at rest and TLS is enforced in transit. Automated backups with point-in-time restore protect against accidental changes, and a restore creates a new server so the existing one is never overwritten. Compute and storage can be scaled from the portal, with storage autogrow preventing the database from running out of space.

All sensitive configuration, including the database connection string, session and token signing keys, and identity provider credentials, is stored in Azure Key Vault. The App Service uses a system-assigned managed identity to read secrets through Key Vault references, so no passwords appear in code, configuration files, or the pipeline. Secrets are rotated by adding a new version in Key Vault and restarting the app.

An Entra ID app registration enables users to sign in with their Microsoft work or school accounts using OpenID Connect. The app registration can accept users from a single organization or from multiple tenants, and its client secret is stored in Key Vault with a documented renewal process before it expires.

Application Insights tracks request rates, response times, failures, and dependencies, with live metrics and full error details for troubleshooting. Application console and HTTP logs are sent to a Log Analytics workspace, where they are retained and queried with Kusto Query Language (KQL). Azure Monitor alert rules notify the team through action groups when failure rates or response times cross defined thresholds.

GitHub Actions workflows build and deploy the frontend and backend automatically whenever changes are merged to the main branch, and can also be run manually. Backend workflows run only when backend code changes, and database schema migrations run from inside the private network when the API starts, so the pipeline never needs direct database access. Workflows authenticate to Azure using OpenID Connect federated credentials, avoiding long-lived deployment secrets.

Common tasks, such as scaling the API or database, restoring data to a point in time, rotating secrets, renewing the SSO credential, changing the domain, and reviewing logs, are documented as step-by-step procedures in the Azure portal, so the owning team can operate the platform independently.