# Prepare for production

Set practical boundaries for an application before users depend on it.

Canonical: https://docs.deliberate.space/operate/prepare-for-production/

Use this guide after an application works and before real users depend on it.
It is a practical review, not a platform certification: the right choices still
depend on the application, its data, and the consequences of an outage.

## Use an address you control

Attach your own domain for a customer-facing application. This keeps the
application address under your control while deliberate. provisions and renews
its TLS certificate. After verification, confirm that redirects, cookies,
trusted-host settings, and generated links use the external HTTPS address.

[Add and verify a custom domain](/deploy/custom-domains/).

## Give the application enough headroom

A Component that omits sizing starts with maximum headroom of `1` vCPU and
`2Gi` memory. These are guardrails, not reservations on the default `standard`
compute class: measured consumption determines usage.

- CPU is throttled at its ceiling rather than terminating the process.
- Memory is a hard safety boundary. Temporary platform pressure can be
  absorbed, but a process that exceeds its ceiling may be restarted.
- Both values bound the impact of a runaway process, memory leak, or unexpected
  spending.

Start with the defaults unless the software documents a higher requirement.
Increase memory after an out-of-memory restart or when usage stays close to the
boundary. Increase CPU when sustained throttling affects response times. Lower
either value when you intentionally want a tighter spending boundary. A
`performance` Component reserves its declared resources and therefore has a
different capacity and cost tradeoff.

Trial uses the same useful default but intentionally stops at one replica per
Component and six active Components across the Team. Its expiring credit and
lower workload scheduling priority make it an evaluation tier rather than free
production capacity. Upgrade when an application needs more services,
replicas, headroom, or predictable production placement.

## Identify every important state

Classify each piece of state as a database, durable volume, object storage, or
disposable data such as a cache. For important state, confirm which backup
policy is active, how long recovery points remain available, and how recovery
is performed.

Backups make recovery possible; they do not prove that the recovered
application is usable. Exercise one recovery before the data becomes
irreplaceable and record who decides which recovery point is correct.

[Review encryption, backup, and recovery behavior](/data/protection/).

## Restrict access and exposure

- Store credentials as secrets rather than plain YAML values.
- Remove temporary credentials and Team memberships used during setup.
- Keep only user-facing routes public; place internal administration surfaces
  behind Private Net where practical.
- Confirm that every declared dependency is intentional.
- Review image vulnerability findings and update dependencies you control.

The platform WAF is a safety net for recognizable malicious traffic. It does
not replace application authentication, authorization, input validation, rate
limiting, patching, or abuse controls.

[Review the application security boundary](/security/).

## Configure failure notifications

Start with symptoms someone can act on: an unavailable public route, repeated
restarts, sustained CPU throttling, memory pressure, a failed backup, or an
unavailable database. Confirm who receives each alert and send a test
notification before relying on it.

[Configure and test alerts](/operate/alerts/).

## Exercise the next change

Fork the production Environment into a disposable preview, apply the candidate
configuration or image override, exercise the important user journey, and
inspect health and logs. Then apply the same desired change to production and
remove the preview.

A preview validates the candidate in an isolated copy. It does not reproduce
production traffic or guarantee that every external integration behaves the
same way.

[Test a change in a preview](/deploy/environments/).

## Record the recovery path

Keep a short operational note with the application:

- the person or Team responsible for it;
- where alerts are delivered;
- the first health and log checks to perform;
- how to reapply the last known-good revision;
- which state needs recovery rather than redeployment; and
- which external credentials or DNS controls are required.

deliberate. operates the platform mechanisms described in these docs. Your Team
still owns application correctness and security, access decisions, acceptable
recovery objectives, external integrations, and the response to alerts.

## Next steps

- [Test the candidate in a disposable Environment](/deploy/environments/)
- [Configure actionable alerts](/operate/alerts/)
- [Review data recovery behavior](/data/protection/)