Deploy yourwhole stackwhole stack

• Compose-native deployments

  Container services, dependencies and environment configuration map directly onto the platform. Public web services get routed; private internal services stay private.

• Workers and daemons

  Queue consumers, schedulers, bots and long-running processes run as first-class services. No HTTP port required, no hacks to keep them alive.

• Scheduled jobs and one-off tasks

  Cron containers become managed scheduled jobs. Migrations and maintenance scripts run as temporary tasks that exist only while they're needed.

• Roadmap

  Managed databases

  Native PostgreSQL, MySQL and Valkey provisioning is planned. At launch, connect an existing managed database through encrypted environment variables.

• Roadmap

  Buckets and persistent storage

  Native object-storage buckets, persistent volumes and managed backups are planned. Initial containers use ephemeral filesystems and external storage services.

• Domains and managed TLS

  HTTP services get a domain and managed certificates out of the box. Point your own domains at the stack when you're ready.

• Environment variables and secrets

  Plain env config alongside encrypted secrets, injected at runtime and reusable across environments. Nothing sensitive lives in the repo or on a box.

• Deployment and application logs

  Build output and streaming per-service runtime logs in one place. When a container dies, you see why — not just that it did.

• Health checks, restarts, rollbacks

  Health checks restart unhealthy containers automatically, and any previous release can be redeployed in one action when a deploy goes wrong.

• Git-controlled environments

  Staging and production as separate, reproducible environments driven by your repository and versioned configuration — not by dashboard archaeology.

• Planned

  Auto container scaling

  Set CPU or memory targets per service and the platform adds replicas when load rises and pulls them back when it falls. No bigger-box upgrades.

• Planned

  Preview environments

  Every pull request gets a temporary, isolated environment with its own URL — review changes running, not just diffed. Torn down automatically when merged.

Bring the stack. Portyard handles production.

# Compose describes the app. This describes production intent.
project: example-app
region: eu-west-2

services:
  web:
    compose_service: web
    public:
      domain: app.example.com
      port: 3000
    replicas: 2
    healthcheck:
      path: /health

  worker:
    compose_service: worker
    replicas: 1

jobs:
  cleanup:
    service: web
    command: npm run cleanup
    schedule: "0 2 * * *"

project: atlas · environment: production
release: atlas-2026-07-21.3

+ Create web service
+ Create worker service
+ Create scheduled cleanup job
+ Configure app.example.com
~ Set web replicas from 1 to 2
! postgres requires an external DATABASE_URL

• Every client stack in one place

  Run client projects side by side — each isolated, all visible from one dashboard and one CLI.

• Clean project boundaries

  Keep resources, environments, domains and access separated between clients.

• Per-client access controls

  Give a developer access to one project, a client read-only visibility on theirs, and nobody keys to the kingdom.

• Planned

  Preview environments per pull request

  Show clients changes running at a real URL before merge — not a screenshot in a ticket.

• Staging & production environments

  Every project gets proper staging and production, driven by the same repository and config.

• Reusable secrets

  Share credentials across a client's environments without pasting them into Slack.

• Reviewable production launches

  Staging can move quickly while production waits for an approved deployment plan. Policy, not convention.

• Roadmap

  Database & file cloning

  Clone production data into staging once native managed databases and storage are available.

• Roadmap

  Managed data backups

  Centralised database and storage backups will follow the native data-service rollout.

• Costs separated by client

  Consolidated billing with per-project usage breakdowns you can attribute to the right client.

• Planned

  Handover without rebuilding

  Planned ownership transfer keeps the environment and deployment history intact when an engagement ends.

• Human and agent audit trails

  See who proposed, approved and applied each deployment plan for every client project.

1. Plan
2. Review
3. Approve
4. Apply

• Read-only by default

  Agent tokens start with visibility, not control. Write access is granted deliberately.

• Scoped access tokens

  Tokens are limited to specific projects, environments and operations — never account-wide by accident.

• Project-level permissions

  An agent working on one client project can't see or touch another.

• Staging-only scopes

  Let agents iterate freely on staging while production stays approval-gated.

• Short-lived credentials

  Credentials expire quickly; nothing long-lived to leak into logs or chat history.

• Deployment plans

  Every change is previewed as a plan — humans and agents both review the same artifact.

• Explicit production approval

  Nothing reaches production without a human approving the plan first.

• Protected destructive operations

  Deleting production data requires additional confirmation — or sits outside agent tokens entirely.

• Complete audit logs

  Every action — human or agent — is recorded with who, what, when and the plan that authorised it.