All guides

Production readiness

Before your first production deployment

A practical checklist for the application, the environment and the team that will operate them.

  • Beginner
  • 5 min read
  • 6 sections
  • Updated
Cover illustration for Before your first production deployment, beginner levelProduction readinessBeginner · 4bde
On this page6 sections
  1. 01Define the smallest complete application
  2. 02Make the environment explicit
  3. 03Decide what healthy means
  4. 04Rehearse recovery
  5. 05Set a cost boundary
  6. 06Bring a concrete setup to onboarding

Define the smallest complete application

Start with a real user journey. List the services needed to complete it: the frontend, API, workers, database and any external dependencies. Record which services need to reach each other and which need a public endpoint.

For each service, identify the source repository, build method, start command, listening port and required configuration. A successful build is useful evidence, but it does not prove that the application can serve a request.

The readiness path
  1. Define the app
    Services, ports, config.
    Gate: Serves a request
  2. Name the env
    Account, region, owner.
    Gate: Secrets listed
  3. Define healthy
    Checks, signals, on-call.
    Gate: Alert has a responder
  4. Rehearse recovery
    Rollback and restore.
    Gate: Restore timed
  5. Set a cost boundary
    Baseline, limits, reviewer.
Figure 1. Each step ends in evidence, not an opinion. The gate after a step is what lets you move on.

Make the environment explicit

Choose the account and region with the people responsible for the application and its data. Give the environment an owner and a clear name. Keep staging and production configuration separate, including credentials for third-party services.

  • Record where persistent data lives.
  • List the secrets each component needs.
  • Decide which endpoints should be public.
  • Identify who can deploy and who can change infrastructure.
production · one account · one region · one owner
A sample production environment. The frontend and the API are the only public endpoints; the frontend calls the API. The API hands jobs to a worker, which reads and writes Postgres and stores files in object storage. Postgres and object storage hold the persistent data.Public endpointsInternal onlyPersistent dataFrontendapp.example.comAPIapi.example.comWorkerjobs, no endpointPostgresbacked upObject storageuploadscallsjobs
  • Frontend connects to API (calls).
  • API connects to Worker (jobs).
  • Worker connects to Postgres.
  • Worker connects to Object storage.
Figure 2. The environment written down: which services answer the internet, which stay internal, and where the data that must survive a redeploy lives.Illustrative · a sample application

Kapten’s infrastructure workflow is the starting point for discussing the cluster setup during early access.

Decide what healthy means

Choose a health check that reflects whether a service can handle work. Identify a small set of useful signals: request errors, latency, worker failures or queue backlog, depending on the application.

Make sure someone can find the relevant deployment and application logs. Define who investigates an alert and how they reach the rest of the team. A dashboard is useful when it supports an agreed response.

Rehearse recovery

Write down how to restore a previous application version and how database changes affect that plan. An image rollback does not automatically undo a schema migration or recover deleted data.

Readiness per service
CheckFrontendAPIWorkerPostgres
Health check reflects real workYesYesPartialYes
Logs findable by someone elseYesYesYesPartial
Secrets listed per environmentYesYesNoYes
Rollback path written downIncluding schema changesYesPartialYesNo
Restore testedn/an/an/aNo
Figure 3. A grid like this one, filled in per service, shows the gaps before production does. Blank answers are the work left.Illustrative · a sample application

Agree a backup policy with the data owner, then test a restore in a separate environment. Record what was recovered and how long it took. Use that evidence to decide whether the recovery plan meets the needs of the product.

Set a cost boundary

Estimate the baseline resources your application needs, including storage and network usage. Define who reviews the cloud bill and what happens if spend rises unexpectedly.

Set capacity limits with expected traffic in mind. Include staging and unused test environments in the review; infrastructure outside production still has an owner and a cost.

Bring a concrete setup to onboarding

You are ready for a useful first conversation when you can share the application shape, target account, region, data dependencies and operating constraints. Keep credentials out of the request form.

Request early access to confirm which connection methods and deployment capabilities are available for your project.

Build with Kapten

Start with one service.
Build from there.

Tell us what you want to deploy. We review each request and follow up about fit and onboarding on your preferred cloud.

Request early access Explore the demo

Free during early access. No card required. Cloud usage billed separately.