Deployment templates and progressive delivery
Forge plans to make deployments simpler and safer with ready-made templates, rollouts that Pulse checks, and hosting for static sites. This page is for teams that deploy with Forge and want to know what is coming. Everything marked Planned is a design, not a feature you can use.
Your servers, load balancer, clusters and DNS stay yours. Forge runs the pipeline, keeps the deployment history and asks for approval. Your own script or tool switches the traffic.
What works today
Section titled “What works today”You can already deploy with your own scripts in a pipeline job. Forge gives you environments with an immutable history and protected environments with approval. It also has rollback, resource groups, releases, a package and container registry, deploy freezes, and id_tokens for clouds without long-lived keys. See Environments, deployments and releases and CI variables, secrets and id_tokens.
Deployment templates Planned
Section titled “Deployment templates ”Templates would be versioned CI/CD components, each in its own repository with documentation and an example project. Components with versions and typed inputs already exist, so templates would use them.
| Template | For |
|---|---|
deploy/compose-blue-green |
Docker Compose on your server over SSH, with two colors, a readiness check and a switch of the upstream in nginx, Caddy or Traefik |
deploy/kamal |
Teams that already use Kamal |
deploy/swarm-rolling |
Docker Swarm with a start-first rolling update and automatic rollback |
deploy/helm |
Rolling updates on Kubernetes, and canary steps once progressive delivery exists |
deploy/static-cdn |
Upload to S3-compatible storage, switch index.html, purge the CDN cache |
deploy/db-migrate |
A migration step that checks compatibility with the previous version |
Templates would take their credentials from environment secrets or from id_tokens, deploy through the environment’s resource group, and write the deployment history by themselves.
Progressive delivery checked by Pulse Planned
Section titled “Progressive delivery checked by Pulse ”A deployment job would declare steps, such as 10%, wait 5 minutes, 50%, wait 10 minutes, then 100%. The target (nginx, Traefik, Istio or Kubernetes) changes the traffic weight. Forge controls the pauses and the decision.
- After each step Forge asks Pulse to compare the new version with the previous one over the same window. Pulse looks at errors, p95 latency and SLO budget for the new
service.version. - Pulse answers better, same, worse or not enough data.
- Worse triggers an automatic rollback, a comment on the merge request and a work item in Orbit under Pulse’s rules.
- Not enough data pauses the rollout, and a person decides with Promote or Abort.
This needs your services to send service.version to Pulse, and a version comparison in the Pulse API Planned.
Other planned deployment features Planned
Section titled “Other planned deployment features ”- Environment targets and an overview of what runs where, with version, who deployed it, health from Pulse and drift from what is expected.
- Forge Pages for static sites and single-page apps on a CDN. They would have your own domains with TLS, previews for merge requests, atomic version switches, one-click rollback and private sites for project members. Pages would be served from a separate address, so user JavaScript never runs on the application address.
- A Kubernetes agent that connects out from your cluster, applies manifests from a repository, and needs no cluster-admin kubeconfig in Forge.
- Feature flags with an API compatible with Unleash.
- DORA metrics: deployment frequency, lead time, change failure rate and time to restore, using Pulse incidents.
Running your application servers on Orbit’s infrastructure as a hosting platform is not part of this plan.