Before your first production deployment

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.

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.

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.

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.