Deploying apps

Deploy a Compose file

1. Under Deployment Management → Compose files, click Deploy on the file and choose a server.
2. Fill in the deployment setup. Everything is optional unless your environment's policy requires it.
3. Review the pre-deployment checks, then confirm.

The deployment setup asks for:

• Environment — development, test, staging or production. The environment's policy decides whether the deployment needs approval or a maintenance window.
• Change request reference, notes and rollback plan — recorded with the deployment. Some environments require them.
• Update strategy for redeploys — Recreate replaces everything at once; Rolling updates one container at a time and can roll back automatically if the new version is unhealthy.
• Git branch or tag, and Redeploy automatically on Git push — for Compose files linked to Git.
• A saved environment variable group to load.

Pre-deployment checks

Before anything runs, PS-pocketEdge shows each service's ports, volumes and limits, and checks:

• CPU, memory and disk — whether the server has enough capacity.
• Host ports — whether any port is already in use.
• Images & architecture — whether each image is available and built for that server's processor.
• Volume paths, secrets & variables, and networks — whether anything is invalid or missing.

Watching a deployment

Open a deployment from the History tab to see its health — Verifying health, Verified healthy or Unhealthy — and its tabs:

• Timeline — every step as it happens.
• Services — each service's state, with Scale to change how many replicas run and Redeploy for a single service.
• Builds — image builds for Git deployments.
• Revisions — every version of the deployment that has run.
• Drift — whether the running app differs from what it should be: the Compose file changed since it was deployed, the Git branch has moved on, or the containers on the server no longer match (missing, unexpected, stopped or on a different image).

From the deployment you can Redeploy, Start, Stop or Restart the whole stack, or Remove it. Removing stops and deletes its containers and networks but keeps named volumes.

Roll back

Roll back to redeploy an earlier state of the whole stack. Choose the last good revision, a specific revision, a Compose file version, or — for Git-linked files — a Git commit. The Compose file itself is not changed.

Promote

Promote copies exactly what a revision runs — the same Compose content, commit and replica counts — into a new deployment in another environment or on another server, for example from staging to production. It goes through the target environment's policy, including approvals.

Backups

Click Backups on a deployment to snapshot its volumes with Backup now, or restore a snapshot. Restoring overwrites the deployment's current data and makes it briefly unavailable while it redeploys.

Example: release demo-web to staging

1. Use the demo-web Compose example and choose an online server with the requested port free.
2. Select Staging, add a change reference such as CHG-1042 and a rollback plan if the policy requires them, then review the preview.
3. Resolve any port, capacity or image checks before confirming. Open History and follow the resulting deployment through Timeline and Services.
4. Verify the application response and deployment health. When you want to copy a tested revision to Production, use Promote and review its target server and policy.

Rolling replaces one replica at a time, stopping its old container before starting the replacement and waiting for readiness. A single-replica service can therefore have an interruption during its update; this strategy does not guarantee zero downtime.