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
Section titled “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.
Give the application enough headroom
Section titled “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
Section titled “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.
Restrict access and exposure
Section titled “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.
Configure failure notifications
Section titled “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.
Exercise the next change
Section titled “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.
Record the recovery path
Section titled “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.