Production Cloud

Production Cloud lists live applications and exposes operations for the selected production release.

It is the operating room for customer-facing apps, not the place where you design new features. Use Studio and Preview to create and test. Use Production Cloud to understand what is live, which infrastructure it uses, and whether a deliberate restart, resize, rollback, or decommission is needed.

Every operation belongs to the selected project. Read the project name, hostname, deployment status, and hosting kind before changing anything. Team permissions protect these actions because they can affect customer availability and cost.

Example: Restart the production order portal only after confirming its live hostname and current incident. Restarting the similarly named development project would not help customers.

Use Production Cloud for the live address, deployment state, database connection when needed, runtime status, and domain actions.

Overview

The overview can show:

• production status and live address;
• hosting kind (static or dynamic);
• recent deployments;
• database connection state;
• custom domain and HTTPS state;
• available restart, pause, resize, publish, rollback, or decommission controls.

The exact controls depend on hosting type, plan, and permissions.

Start with status and recent deployment information before pressing an action. A static release will not present the same server controls as a dynamic app. A teammate may see the page while lacking permission for a high-impact operation, which is expected role behavior rather than a broken button.

Example: A static portfolio may show its live address and deployments but no server-size control. A dynamic CRM can show compute, database state, and restart options.

Development Cloud vs Production Cloud

Development Cloud manages the workspace used for building and Preview. Production Cloud manages the release customers use. Restarting one does not mean you restarted the other.

Use the hostname and page heading to orient yourself. Development can sleep without taking the production release offline. Production can have an incident while the development Preview remains healthy. Diagnose the environment where the symptom actually occurs.

Example: If only customers at the custom domain see an error, investigate Production Cloud. If only Studio Preview is warming up, investigate Development Cloud.

Dynamic compute

Dynamic apps use server compute. Available plans describe CPU, memory, scale behavior, and included capabilities. Choose based on measured workload, not the largest option by default.

Where autoscale-to-sleep is offered, compute usage is recorded by awake time. A sleeping instance is not billed as awake compute; other plan, storage, egress, or product charges may still apply.

Choose a size that supports the observed workload with reasonable headroom. More CPU or memory can help a genuinely constrained app, but resizing does not repair an application bug, bad database query, or unavailable external provider. Review performance evidence before changing the plan.

Example: Resize when monitoring shows sustained memory pressure during normal traffic. Do not resize merely because one payment provider returned an error.

Restart and pause

Restart when the running service needs to reload or recover. Pause only when you intend to make the production app unavailable. Both are operational actions and may require confirmation.

Restart is temporary interruption followed by recovery. Pause intentionally keeps the app unavailable until resumed. Communicate customer impact and confirm there is no active deployment before operating the service.

Example: Restart after a confirmed runtime process failure. Pause for a planned maintenance window only when taking the app offline is the intended result.

Rollback

Rollback restores a previous production release snapshot. It is appropriate when a newly published version causes a customer-impacting problem.

For external managed Postgres, code rollback does not automatically rewind the provider's data. Use the database provider's backup/recovery controls for data restoration.

Rollback is a production incident tool, not the normal way to edit a feature. Choose a known healthy deployment and verify the critical customer path after it becomes active. Keep investigating the failed release in development before publishing again.

Example: A new checkout deployment prevents every order. Roll back to the last working deployment, confirm orders work again, then repair the new version in Studio.

Decommission

Decommission removes the production deployment. It does not mean the development project or independently owned domain should be deleted. Review assignments and recovery needs first.

Before decommissioning, record any recovery requirement, decide what happens to the domain, and confirm database retention with its provider. The development project can remain for future work even when no production deployment is running.

Example: End a campaign app's production deployment, park its domain, retain the project for next year's update, and keep database records according to the campaign's retention policy.

Always confirm the project name and production address before restart, pause, rollback, resize, or decommission. These controls affect customer availability.