How Builds & Deployments Work

Every Web Application and Background Worker on d2o PaaS goes through the same pipeline: your source code is turned into a runnable image by Cloud Native Buildpacks, and that image is then deployed into the Environment. This page explains each stage and the knobs you control.

The pipeline at a glance

1. Source — new code arrives on the platform-hosted repository’s main — pushed by you, your CI, or a linked GitHub/GitLab branch.
2. Build — buildpacks build a version of your app from that commit using the framework you declared for the app. No Dockerfile is required.
3. Release — if the app has a release command, it runs once against the new version before anything else starts.
4. Deploy — new instances start and must pass their health check before they take traffic. With Automatic deployment on (the default) this happens automatically; with it off, the build waits until you deploy it yourself. A version that never becomes healthy is rolled back automatically. See Deployments, Health Checks & Rollback.

Each deployment is pinned to the exact image produced from your commit — the platform records the image by its digest, so what runs never silently drifts from what was built.

Where your code comes from

The platform hosts a git repository for every app — or one per Environment that several apps share. Code reaches it in one of three ways: you push to it (below), your CI pushes with a deployment token, or you link a GitHub or GitLab branch and every push there is deployed. Pointing an app at an arbitrary git URL isn’t supported.

The app’s Deployments tab in the dashboard shows ready-to-paste push commands (the remote URL embeds an access token), or the CLI configures a paas remote for you:

paas git remote -o acme -p shop -e production -a web
git push paas main

The CLI’s paas remote uses SSH by default — register a key first with paas keys add — or pass --https for an HTTPS remote whose push token is kept by git’s credential helper. See Deploying with Git Push.

Apps always build from the platform-hosted repository’s main, wherever the code came from.

Apps that share an Environment’s repository and have the same source directory and framework share one build: the image is built once per push and deployed to each of them, each running its own process.

Builds and frameworks

Builds use Cloud Native Buildpacks: the platform builds an image straight from your source using the buildpack for your app’s framework. Every Web Application and Background Worker declares its framework when you create it — it must be one of the supported frameworks, and an app without one is rejected up front rather than deployed broken. An app whose build produces more than one process type can choose which one to start (the app’s Process setting).

Build and runtime connectivity differ; see Network access.

While a build is running, the app’s status and log views tell you the image is still building; a failed build shows as Failed in the deployment history, and the Organization’s owner gets an email about it (once per failure, when email is configured on the installation), so a broken push never goes unnoticed.

Network access

Blocked private ranges include 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and 100.64.0.0/10. An authenticated registry still needs a publicly reachable address for a build. Vendor a dependency if it cannot be served from a reachable endpoint; do not query a live database during compilation.

Use attachments for managed service addresses and credentials. Do not construct internal database hostnames yourself or expect a local machine to reach them. Run diagnostics from the app’s console. For a public web service, use its displayed HTTPS URL or custom domain, not a guessed hostname. Workers have no public URL.

An unreachable dependency is different from an invalid credential: first check the address and Environment, then connection timeouts and authentication. Applications should use bounded timeouts, reconnect, and back off when retrying transient failures; see Designing Apps for d2o.

Automatic deployment

Automatic deployment is a per-Environment setting, on by default. While it’s on, every successful build of new code is deployed automatically.

Turn it off when you want to control exactly when code ships (a production Environment, say). The platform still builds every push — the build simply waits, showing as Built (waiting to be deployed) in the deployment history, until you deploy it.

You set Automatic deployment when creating an Environment, and change it later in the dashboard under Environment Settings → Deployment. The Environment’s overview shows whether it is currently enabled.

Deploying manually

When Automatic deployment is off (or you just want to force a rollout), trigger a deployment from the CLI:

paas deploy -o acme -p shop -e production -a web

This ships the newest successful build — even in an Environment with Automatic deployment off — and rolls the app out. Triggering a deployment requires the deploy permission on the project. In a promote-only Environment, promote into it instead — paas deploy is refused there.

Build and promote-only Environments

An Environment either builds from source (the default) or is promote-only: it never builds, and its apps run the versions promoted into it from another Environment. Pushes to a promote-only Environment are refused. See Pipelines, Promotion & Rollback.

Tracking what’s deployed

The Deployments tab of an app lists that app’s deployments, newest first — click Load more for older ones. Each entry shows the deployment number, commit message, short SHA, branch, who pushed it, whether it was a build, a promotion or a rollback, and its stage (Received, Queued, Building, Built, Running release command, Releasing, Starting, Live, Failed, Rolled back, Rollback failed, or Replaced), with the newest Live entry marked current. A shared build also names the other apps it deployed. For every app at once, open the Environment’s Deployments tab.

From the CLI:

paas releases -o acme -p shop -e production   # recent deployments
paas status   -o acme -p shop -e production -a web   # current sync/health status

paas deploys list (alias paas releases) shows 25 deployments per page; add -a web for one app’s deployments, and follow the More: paas deploys list --before <n> hint (or pass --limit, up to 100) for older ones.

Next steps

• Deploying with Git Push
• Deployments, Health Checks & Rollback
• Supported Frameworks
• Logs