Choose a hosting model before choosing server sizes
Our recommendation for a small team is to start with a managed application runtime and managed PostgreSQL when those services fit the app’s requirements. Use a virtual machine when you have a concrete need for that control and someone responsible for patching, deployment, monitoring, and recovery. A lower infrastructure bill can require more operating work.
This guide is a framework-neutral planning example for an app with accounts, a relational database, private file uploads, and background jobs. It is not a production configuration or a promise about how many users a server can support. Workload measurements, data requirements, and an explicit availability target must settle the final design.
Connect the pieces
The browser talks to the web application over HTTPS. The web application checks permissions, reads and writes PostgreSQL, and issues temporary access to private files. A worker handles jobs that should survive beyond a web request, such as generating a report or calling another service.
- Web runtime: run the application, expose a health check, and decide how traffic reaches a healthy process.
- PostgreSQL: store application records, manage connection limits, and select backups and failover around the business recovery requirement.
- Object storage: keep uploads outside disposable application containers and coordinate file identifiers with database records.
- Background work: choose a durable queue and worker process; document retries, duplicate protection, and failed-job handling. A queue may use a database or a separate service depending on the application.
- Email and integrations: use scoped credentials, handle delivery failures, and budget for each provider separately.
- Operations: include DNS, TLS, secrets, logs, metrics, error reporting, release history, and recovery instructions.
Keep the application and database close in network terms where practical. Check outbound connectivity, private access, and region requirements before provisioning. A marketing site’s static hosting configuration is not automatically a runtime for an application with server processes and persistent data.
Three hosting choices to compare
Managed runtime with managed data services
Shortlist a platform that supports the app’s runtime, worker process, release tasks, and private networking needs. The platform operates more of the hosting layer; your team still owns application behavior, credentials, migrations, alert response, and recovery validation. Confirm backups and rollback behavior separately for each service.
Cloud application services on AWS, Azure, or OCI
Start from the provider where the team already operates, then select the runtime and network design around the app. Use the PostgreSQL category and object-storage category for the data services. Budget for network gateways, load balancing, observability, and support where applicable. This library does not yet compare those runtime products or verify a full regional quote.
Virtual machines with an explicit operating owner
A VM can be appropriate when the application needs control over its host. Name the owner for operating-system updates, process supervision, certificate renewal, backups, disk capacity, and failure recovery. Putting the web app and database on one machine also combines their failure domain. Evaluate that risk against the downtime the business can accept before treating it as the production baseline.
A transparent cost worksheet
Use these illustrative inputs to request comparable estimates. They are assumptions for a worksheet, not measured requirements or a priced recommendation:
- One production environment running for 730 hours in a planning month, plus a separately sized staging environment. Actual calendar months vary.
- Two web processes and one worker, initially requesting 1 vCPU and 2 GiB memory each. Confirm the runtime’s resource units and minimum billable size.
- A managed database starting at a 2-vCPU, 8-GiB memory planning target and 100 GiB storage. Add the topology needed to tolerate one zone failure where supported; count every billable node and storage component.
- A seven-day database recovery requirement. Verify the available recovery points, backup charges, and restore procedure for the selected service.
- 100 GiB of retained object data, 100,000 writes, 1,000,000 reads, and 100 GiB of internet delivery per month. Add old versions, recovery copies, and replication if selected.
- 10 GiB of log ingestion and 30 days of retention as an initial observability assumption. Estimate metrics, traces, error reporting, email, and integration usage separately.
Choose an exact region and quote currency before entering rates. Record the source URL and check date for each rate, and confirm whether the provider bills GB or GiB, provisioned or used capacity, and requested or actual resources. Equal CPU and memory labels do not establish equal performance.
A complete monthly estimate combines runtime, workers, database nodes, storage and performance, chargeable backups, object operations and delivery, network services, observability, and support. Add engineering and operational support as a separate line. Taxes, discounts, and credits should be explicit. No verified rates are attached to this example, so it does not produce a total or identify a cheapest provider.
Assign responsibility before launch
The provider’s managed service responsibility does not cover all of the application. Put a named person or contracted team against each task:
- The product owner sets acceptable downtime, acceptable data loss, retention requirements, budget, and release approval rules.
- The application owner maintains dependencies, validates permissions, reviews migrations, handles job failures, and keeps the release and rollback procedure current.
- The infrastructure owner configures access and secrets, monitors capacity and spend, verifies backups, and rehearses recovery with the application owner.
- The incident owner receives agreed alerts, decides when to escalate, and communicates recovery progress. Set response hours and exclusions in writing.
One team can hold several responsibilities, but each task needs a clear owner. Hapy’s cloud infrastructure service can cover agreed implementation and ongoing work; support coverage and response commitments are defined during scoping.
Prove the plan before calling it ready
Deploy a representative staging environment. Test a release, a failed migration, a worker retry, an unauthorized file request, a database restore, and a file restore. Record the observed recovery steps and time; do not substitute a provider availability claim for an application test.
Load-test the important user journeys and scheduled work, then adjust the worksheet. Keep a current architecture inventory, account owners, a restore record, and a rollback plan. For the database implementation side of this work, see PostgreSQL development and maintenance with Hapy.