Manual deployments on DigitalOcean App Platform: where the process breaks
While releases are manual, every rollout is a set of steps that live in one engineer's head: build the image, push it, wait for the restart, adjust the application parameters in the DigitalOcean App Platform console.
Skip one step or do them in a different order — and the staging environment is running the previous version, while production already has the new one. No one can say exactly what went to production until they look at the panel.
The most fragile area is environment variables and secrets. They are transferred between environments manually, copying values from window to window, and sometimes just from chat.
One typo in a database connection string or a forgotten variable for a background process causes a release failure that is then hunted for hours in logs.
This is how environment drift accumulates: the test environment and production stop being copies of each other, and system behavior stops being reproducible.
The cost shows up at the moment of failure. Recovery turns into archaeology: you need to remember which version was previous, what settings came with it, and what changed between rollouts.
Recovery time grows with each such iteration, while the change history remains smeared across chats and someone else's memory, rather than in one place.
Continuous delivery does not break at build time — it breaks on environment inconsistency and the absence of a repeatable manual rollout.
Below we look at how deployment automation closes these gaps: what is described declaratively, where secrets are stored, and why rollback stops being a separate operation.
What automation of build, tests, and rollout provides
While a release is built and rolled out manually, the result depends on who made the changes and in what order.
Build automation removes this variable: the build runs on every commit according to one scenario, and tests serve as a gate — a version that fails validation never reaches the environment.
Environment repeatability rests on configuration being described in the repository next to the code: the validation environment is brought up from the same description as the production environment, and the “it works on my machine, not yours” discrepancy stops being a separate task.
On DigitalOcean App Platform, the environment, domain, variables, and background jobs are defined by a manifest rather than restored from memory.
Rollout time shrinks not by speeding up delivery, but by eliminating pauses: waiting for an engineer, approvals, manual checklist checks. A rollout becomes a short, predictable event that can be scheduled at the end of the day rather than in a minimum-load window.
Release stability grows for a specific reason: an entire class of failures goes away — configuration desynchronization and a skipped step. Code errors remain, and they are caught before rollout.
Rollback is a return to the previous built version, not a rebuild under pressure, so recovery takes minutes.
The effect can be checked with four numbers: time from commit to updated environment, share of rollouts without manual intervention, share of failed releases, and recovery time. They are measured before and after moving to the pipeline — and they show exactly what changed.
Approaches to continuous rollout: comparing modes
Rollout methods on the platform differ not by convenience but by what the team gets at the moment of failure: rollback in seconds or a manual investigation into which commit went live.
In DigitalOcean App Platform, the baseline scenario is automatic rollout from a branch, and it is almost always extended to match the real cost of a mistake.
Below are working options that we set up, with the limitations of each.
| Option | When it fits | Limitations and cost |
|---|---|---|
| Auto-rollout from branch on merge | One service, short cycle, tests in CI | No staged release: an error goes to everyone at once. Rollback is a re-rollout of the previous commit, version history is blurred |
| Rollout by immutable tag from CI | Multiple services, audit needed and instant rollback | Requires tagging discipline and a separate build step; the environment is described declaratively in full |
| Staged release: part of traffic to the new version | High cost of failure, metrics available for switch criteria | Requires two components, variable duplication, and observability; version mismatches are harder to debug |
| Preview environment for every merge request | Validation of changes before production rollout | Data is not production, migrations must be replayed separately; the number of simultaneously live environments grows |
The selection criterion is simple: the more expensive the failure and the less visible it is, the earlier staged release is needed. For other cases, immutable builds and instant rollback are enough — this covers most incidents without a second environment.
How we implement automation: stages of work
We start not with tool configuration but with an analysis of current releases. Manual release breaks predictably: environments diverge, variables drift, rollback depends on a specific engineer's memory.
Below is the order of work after which a change follows a single path and the previous version is restored in one step.
- Infrastructure and release process audit: where the application is built, where variables come from, what is still done manually. We mark the steps that wait for a specific person.
- Environment scheme: we separate development, test, and production environments, and assign each its own secrets and domain. The same configuration with different variable values removes the class of “works in test” errors.
- Build preparation: we describe the application declaratively so the image builds identically on any machine, and enable dependency caching — a rebuild with no changes goes noticeably faster.
- Pipeline setup: we connect the repository to DigitalOcean App Platform, define branch triggers and mandatory checks before rollout. Deployment starts only after tests pass.
- Secrets and access: we move keys and variables to the platform's secure vault, restrict permissions for the production environment, and actions are logged.
- Rollback verification: we intentionally release an incorrect variable and a failing migration — we make sure the previous version is restored with one action and data remains intact.
- Handover to operations: we provide configurations, the environment scheme, and the release procedure, and run a real change from commit to production with the customer's team.
What you keep after implementation: artifacts and procedures
Implementation ends not with production launch but with handover: everything configured remains in your repository and documentation, not in chat and one engineer's head. Below is exactly what you receive and can verify.
- Configuration description — application manifest, variables and secrets per environment, service and database bindings: the environment is brought up from the repository, not assembled manually.
- Environment scheme — which environments exist, which branch rolls out where, which checks run before production, and which data can be used in each.
- Access policies — roles and permissions for changing configuration and releasing, the procedure for issuing and revoking keys, where secrets are stored and who can see them.
- Release procedure — the path from commit to production: mandatory review, rollout order, success criteria, and the rule for rolling back to the previous build.
- Team instructions — how to add a variable, connect a service, roll back a release, and bring up an environment from scratch: step by step, with commands.
- Monitoring map — which metrics and logs we collect, where alerts arrive, and who responds.
- Runbook for common failures — what to do in case of a failed deployment, database unavailability, or key leak.
The documentation lives in the same repository and is updated together with the code: changes go through review, so six months later the procedure does not diverge from the actual state of the infrastructure.
Case study: from manual rollouts to an automated pipeline
The client came with a fully manual release: build on the developer's machine, copying artifacts to the server, migrations, and process restarts according to instructions.
Three environments diverged in settings, and the release window was chosen at night — during the day, a rollout would have taken half the team's workday.
Metrics for the quarter before automation: release — from four to six hours, out of 40 rollouts nine ended in rollback, that is almost a quarter.
Recovery of the previous state — 40–60 minutes manually, and the order of steps depended on one engineer who remembered their sequence.
What we changed
Build and release were moved to DigitalOcean App Platform: rollout is triggered by a commit to the main branch, migrations run as a separate step with validation, and environments are described by configuration in the repository.
Manual operations — copying artifacts, restarting processes, editing variables on the server — were retired from operations, and release access was granted by role instead of a shared key.
What the result was
A release takes 20–25 minutes; release time dropped by about 12 times, with only about three manual actions left: confirm the launch and view the report.
The share of failed rollouts for the quarter fell to 3–4%; rollback is switching to the previous built image in a couple of minutes, and a night window is no longer required. The engineer who led rollouts returned to product tasks.
How App Platform differs from deployment on servers
Managed deployment shifts part of the responsibility to the platform: it builds the image from the repository, rolls out the new version, maintains certificates, distributes traffic between instances, and rolls back the release if the health check fails.
DigitalOcean App Platform works exactly this way: the engineer describes the application, environment variables, and scaling rules, not the operating system underneath.
Deployment on virtual servers is the opposite model. We install and update packages ourselves, configure process isolation, services, log rotation, certificate issuance, and backups, and with a single host any of these details becomes a single point of failure. Flexibility is higher, but ongoing maintenance remains with the team.
| Option | When it fits | Limitations |
|---|---|---|
| Managed platform | Standard application, backend, background jobs | No access to the kernel and system services, some settings are defined by the platform |
| Virtual server | Need custom packages, daemons, non-standard network | Updates, monitoring, and fault tolerance are on the team |
| Container cluster | Many services, strict isolation requirements | Requires specialized engineers and ongoing operations |
The limitations of the managed approach are noticeable on non-standard tasks: an arbitrary system daemon cannot be launched, the build follows platform rules, and long-running tasks and persistent state are moved to separate services.
For a standard application with a database and queue, these boundaries are sufficient — in return, the team does not spend time on host updates and monitoring. A custom environment wins where requirements go beyond the platform.
Common technical concerns before starting
Concerns before starting are not about the tool itself, but about edge scenarios: migrating a working project, keys, environment separation, and a failed release on DigitalOcean App Platform. Below are short answers for each.
Will a working project move without rewriting?
If the application already builds into a container image, it runs as is — only the build and placement change. The old environment keeps running until the switch.
What can the platform not do?
Long-lived processes with state on disk and custom system packages outside the image are moved to a separate node or managed database. Usually this is one or two places across the entire environment.
Are we locking ourselves into one provider?
Inside is a regular container and environment variables; the application description is declarative. Moving to another provider means changing the deployment address, not rewriting the service.
Where are secrets stored and who can see them?
Database keys and tokens for external services are in a secure vault; the repository contains only variable names. Production values are available to a few people, do not appear in logs, and rotation is scheduled and incident-driven.
How do we separate environments?
Each environment gets its own application and its own database: schema changes are run on a copy with anonymized data. A branch with changes gets a temporary environment and loses it after merge.
A release broke production — what next?
The platform stores previous builds, so the return is switching to the previous image in minutes, without a rebuild. We prepare reverse migrations in advance: rolling back the code will not save you with an incompatible schema change.
What we need from you to discuss the task
The more precise the input data, the fewer assumptions in the estimate and the faster the plan becomes actionable.
Below is what is worth sending or discussing on the first call; if something is missing, that is not a problem — we will collect part of the data ourselves, but then implementation timelines shift to a discovery stage.
- Service composition: how many application components are built and run separately — web frontend, API, background workers, scheduled tasks — which of them are public, which listen to a queue.
- Current release process: from which branch and on what event the build is rolled out, who presses the button, whether there are manual steps, and where it most often breaks.
- Environments: which environments are needed — pre-production, production, temporary ones for branch validation — and whether each must have its own variables and database.
- Access and boundaries: repository, image registry, where secrets are stored, whether there are restrictions on granting permissions, and who approves connections.
- Pre-rollout checks: mandatory automated tests, image build, schema migration validation, manual confirmation before the production environment.
- Release procedure: allowed window, zero-downtime requirements, how you roll back to the previous version, and who makes the rollback decision.
- Expected implementation timelines and the nearest goal: a one-time move of releases to automated mode or immediate setup of several environments with checks.
In response, we will send an estimate and plan: a breakdown by stages, which work we do and what remains on your side, the launch scheme, and the order of connecting environments. Suggest a convenient time — we will discuss the task in detail.