Give your first API a resource budget and a recovery plan.

This is an illustrative planning scenario for an independent builder, not a customer story or a measured capacity result. The application records equipment loans for a small club: an authenticated member can see available items, create a loan and return it. A record matters more than a fancy deployment diagram, so the first design should make failed writes and lost data easy to investigate.

Choose the minimum useful architecture

Use one API process, one database and a reverse proxy for the public HTTPS endpoint. Keep the database reachable only through the intended local or private path. Give the application its own operating-system identity, with access to the files it needs. Keep deployment files separate from persistent data so a release does not replace the database or uploads.

Sharing an instance keeps configuration and investigation manageable for a first deployment. It also ties the components to the same restart, disk and failure boundary. Accept that tradeoff deliberately. If the application requires independent recovery or the database consistently competes with the API, consider separating them before increasing everything at once.

Budget for the busy moment

Do not size only for an idle process. The worksheet below uses invented planning allowances to demonstrate the calculation. They are not measurements of this application, benchmarks or minimum requirements. Replace them with observations from your runtime and database, including a representative deployment.

The Build starting plan currently specifies 2 vCPU, 2 GB RAM and 50 GB SSD. Those figures make it a configuration to investigate for this worksheet, not proof that the stack fits. Catalogue GB and a tool's MiB readings are different units; inspect the actual system totals. Linux's available-memory estimate accounts for relevant reclaimable memory, so low free memory alone is not a sizing verdict. See the kernel explanation of MemAvailable and the measurement guide.

CPU and disk need separate decisions. Record request durations and database waits before adding vCPU. Budget disk for the operating system, retained releases, database growth, logs and temporary recovery work. An upload feature creates a different storage problem from a small structured record; give it a size limit and a retention decision.

Know the upfront cost

The following example uses Build with its default resources and no added recurring options. Its monthly subtotal is $14.00 USD. Values are generated from the current configurator catalogue so the price table follows checkout.

A six-month or annual period lowers this catalogue's upfront total relative to paying the undiscounted monthly subtotal for the same number of months. It does not add resources, establish a renewal price or make an untested architecture suitable. Choose a period you can commit to, review service and billing details, and allow separately for a domain, any external services and network fees.

Verify one complete request

Before opening the application to its intended users, confirm server access and recovery access, install a supported runtime, and record the release you deploy. A service definition should identify the executable, working directory and runtime user. Systemd's Restart= setting controls specified failure behavior; a restart loop still needs diagnosis. See the service manual and the deployment walkthrough.

Test locally first, then through the real HTTPS name from another connection. With Caddy, automatic certificate management depends on valid name configuration and a working validation method; the common HTTP and TLS-ALPN challenges need reachable inbound ports 80 and 443 respectively. See the Caddy HTTPS prerequisites. A local success cannot rule out a DNS or proxy problem, as the request-path guide explains.

Make the application check specific: create a disposable equipment item, lend it, confirm that a second request sees the stored result, then return it. Check authorization as well as a simple health endpoint. Record expected responses before testing, and keep credentials and member data out of logs shared for troubleshooting.

Prove a small recovery

Back up the database with a method appropriate to the engine and recovery objective. PostgreSQL documents separate logical, filesystem and continuous-archiving approaches; the right choice depends on how you need to recover. See its backup overview. If item photographs are uploaded, include those files and the relationship to their database records.

Run a restore exercise into a separate test database and directory. Find a known item and its corresponding file, then check that the application can read both. Write down the backup selected, data timestamp, steps required and actual result. The first restore guide develops this exercise. An optional catalogue backup selection does not prove that this application-level recovery works.

Make the next decision from evidence

Stay with the simple design while its measured behavior and recovery requirements fit. Investigate a stopped application or resource warnings before assuming that a larger plan is the answer. Choose Malaysia, Romania or Switzerland for the server, then confirm resource allocation, backup location and service scope. This scenario establishes no facility, request capacity or delivery time.

Configure Build and review every option. The link opens the starting plan; check the selected period and any saved choices before continuing. Getting payment details does not install the equipment-loan application.