Operations and recovery

Backup and restore tests, guarded releases, image checks, outbound controls and incident history.

Understand deployment failures

An app's Overview shows a diagnosis and the next action. An app without a release says “No code deployed yet.” Build failures, unreachable servers, capacity problems and failing health checks link to the relevant app page.

Infrastructure and server readiness

Open Resources, Infrastructure map to follow providers, attached servers and app placement. Capacity is reserved CPU and memory, rather than live utilization. Open Connect a server to generate an enrollment command and follow connection, runtime, tunnel and workload checks. Install commands contain a short-lived enrollment credential and are shown once.

Deploy a small HTTP workload to the attached server or its cluster, then run the readiness test. CloudJod checks a recent authenticated workload report and requests its health endpoint through the server's tunnel. A configured tunnel address alone does not pass this test. A readiness result expires after fifteen minutes; the agent's sandbox report is not hardware attestation.

Review and guard releases

Deploying an image or releasing a build opens a review of its pinned digest, resource changes and changed environment-variable names. Secret values and digests are omitted. Changes after review require a fresh review.

A guarded release restores the previous serving image if the replacement fails its health check. A traffic canary first runs a separate candidate and sends it 1–50% of HTTP traffic. Its health window starts after the edge accepts the traffic split. Canaries require a stateless HTTP app on one server, an extra app slot and spare capacity. Apps with local volumes, init containers, sidecars or release commands use their supported deployment flow instead.

Follow progress or cancel under Delivery, Safe releases. Rollback restores the serving image; database changes and independent secret edits need their own recovery plan. One-replica replacement can interrupt requests during startup.

Check software and control secrets

Under app Settings, Security, scan an image for vulnerabilities and download its CycloneDX software bill of materials. The worker uses Trivy under a dedicated unprivileged account. When an exact GitHub Actions signing identity is configured, Cosign checks the image signature against that identity and issuer. Missing tools, unavailable images and failed checks are shown explicitly.

Organization owners and team administrators can set release requirements under Settings, Software security. Admission applies to new releases from the API, builds and hooks. Evidence must match the exact image digest, current signing policy and a twenty-four-hour validity window. Signature verification is unavailable for images held only in the local build cache; publish and sign an image in a supported public registry to use signature enforcement. Signature verification alone does not attest the whole build process.

Secret usage lists the workload types inheriting each app secret. Supply a replacement credential to apply it and wait for a fresh healthy app observation. A failed test restores the previous encrypted value when no newer app edit has superseded it. Revoke the old credential with its provider after success. This test proves app health, rather than every possible use of the credential.

Restrict outbound connections

Choose public outbound access, selected public IPv4 destinations and ports, or tenant-network-and-DNS-only access. Rules apply to replicas, background processes and one-off commands. They cannot permit metadata endpoints or override platform isolation. A policy change reconciles existing containers. Assigned attached agents must be updated to a compatible release before they can accept a restricted policy.

Backup and recovery center

The operator organization owner can open Settings, Backup & recovery. Full-installation backups contain multiple tenants and are not available to ordinary tenant owners. Connect an S3-compatible HTTPS destination, select it, and enable uploads of scheduled backups. Credentials are encrypted in the provider account. Local capture scheduling continues through the installation's backup timer.

The center shows local captures, confirmed offsite uploads and tested restores. Verification checks compatibility and encryption-key access. A restore test creates a generated database with a limited role, applies the current schema, validates records, tests up to 1,000 encrypted environment values and copies state into an isolated directory. It does not start apps or send public traffic. Restore previews retain that database and state for inspection for up to twenty-four hours. Low disk capacity blocks capture, upload spooling or restore before it consumes the live database's reserve.

Keep the master keyring separately from backup archives. The dashboard never overwrites the live database. Disaster recovery and downloading an offsite archive use the operator CLI and a separate recovery host; see cloudjod-backup help. A successful database and state restore test does not prove every application will boot correctly.

Incident history and audit exports

Settings, Incident timeline combines releases, build outcomes, observed server outages, configuration changes and security operations. Filter by category, search descriptions and load older events. Configure an external storage destination under Software security for daily compressed JSONL exports, or export on demand. Exports record stable event IDs, a checksum and a watermark. Boundary events can repeat between exports, so importers should deduplicate by event ID. Storage retention and object immutability depend on the destination's configuration.

Next: The CLI and the API