Git-Based Deployment Workflows for Edge and Serverless Applications
Git-based deployment workflows are not a best practice so much as they are a solved problem that many teams are still solving badly. The serverless computing market was valued at $25.76 billion in 2025 and is projected to reach $108.39 billion by 2035 (source needed); Gartner projected that 75% of enterprise-generated data will be processed at the edge rather than in traditional data centers by 2026. At that scale, ad-hoc deploy scripts and manual promotion steps are not inconveniences — they are the cracks in a foundation that the entire building is resting on. The solution is to make the repository the single source of truth for what runs where, such that every deployment action is version-controlled, auditable, and reversible. This article walks through how to structure that in practice.
Two Distinct Flavors of Git-Based Deployment, and When Each One Applies
The term "GitOps" has accumulated enough definitional baggage to be almost useless without qualification. There are two meaningfully different patterns under the umbrella, and conflating them is how teams end up with the wrong toolchain for their target infrastructure.
The first pattern has its origins in a 2017 formulation from Weaveworks: declarative desired state lives in Git, and a continuously running reconciler enforces that state against a live cluster. Tools in this lineage watch a Git repository and drive cluster contents toward whatever the latest commit describes. When a remote edge node loses WAN connectivity, the reconciler keeps the deployed state correct from the last-known commit — a safety property most application-layer tooling cannot provide.
The second pattern is older in spirit, though its modern form descends from the Heroku model: connect a repository to a platform, and let each push trigger a build and deploy. Git becomes the deployment contract. No separate reconciler, no agent running inside the cluster. The platform watches the branch and acts.
For teams deploying edge functions, serverless compute, and statically generated frontends, the second pattern is the operative one. Infrastructure GitOps becomes relevant again when a team also manages Kubernetes at edge nodes, or operates in environments where connectivity is intermittent and the reconciler's guarantee matters. The guidance that follows focuses on the application layer, with notes on where the infrastructure pattern re-enters the picture.
Choosing a Branch Strategy That Maps Cleanly to Deployment Targets
Every long-lived branch should have exactly one deployment target. That is not a preference; it is the load-bearing principle of the entire workflow. Ambiguity in this mapping is the proximate cause of most "it worked in staging" failures, where "staging" turns out to be a branch that shares a deployment target with two other branches and hasn't been rebased against main in eleven days.
The mapping that works reliably for edge and serverless teams is direct: main deploys to production, a staging branch deploys to a pre-production environment that mirrors the production infrastructure class, and feature branches produce ephemeral preview URLs. Each branch has one target and one target only.
Trunk-Based Development vs. Gitflow
Trunk-based development, where short-lived feature branches merge frequently into main, suits edge and serverless platforms well. Build pipelines on these platforms are fast enough that the feedback cycle doesn't punish frequent integration, and keeping feature branches short-lived means preview environments are similarly transient, which limits cost and confusion.
Gitflow, with its long-lived develop and release branches, introduces meaningful lag between the code a developer writes and the deployed reality that gets tested. It is defensible for teams operating under regulated release windows where that lag is intentional. For every team I've seen try it without a regulatory mandate, it produces branch divergence that becomes a merge-day problem.
Monorepo and Multi-Repo Considerations
When multiple edge functions share a single repository, the pipeline must detect which service changed and build only that service. Full-repository rebuilds on every push fail to scale as the codebase grows, and they introduce deployment surface area for services that haven't changed.
The multi-repo pattern that has proven reliable for larger edge deployments separates each service into its own repository with its own CI pipeline, and maintains a central GitOps repository holding environment overlays and a versions lock file. When a service's CI pipeline produces a validated artifact, it opens a pull request to the GitOps repository that bumps the service's version in the lock file. Promotion is explicit, gated, and traceable. At remote edge nodes where network connectivity is unreliable, the last committed lock-file state is the authoritative desired state regardless of whether the node can reach the origin.
What Preview Environments Actually Give You and How to Structure Them
A preview environment is not a shared staging server. It is a unique, isolated deployment produced from a specific branch or pull request, running on the actual platform runtime, with the actual CDN routing and the actual function execution environment. The distinction matters because a category of bugs only surfaces when the code runs inside a V8 isolate, or behind a specific WAF rule, or subject to the memory limits of the target compute class. A shared staging server approximates those conditions. A preview environment reproduces them.
What to route through a preview environment is relatively clear: edge logic, routing rules, serverless functions, and static assets. What to stub or sandbox is equally clear: third-party payment processors, production databases, and any external API that produces side effects. Environment variables and platform-level secrets handle the routing distinction, pointing preview deployments at sandbox credentials and test endpoints rather than live production backends.
Two operational hygiene points matter here more than they appear to in theory. First, preview environments must be torn down automatically when a branch is deleted or a pull request is closed. Uncleaned previews accumulate cost and produce a graveyard of stale URLs that stakeholders occasionally mistake for current deployments. Second, previews should require authentication before they're accessible. A preview URL that indexes in Google is a pre-release content exposure incident.
Preview environments are most valuable for frontend changes and edge-function logic. Deep stateful changes, including schema migrations and durable-state mutations, require a migration-aware promotion process that preview environments alone cannot adequately validate.
Structuring CI Pipelines So They Enforce Quality Gates Before the Edge Ever Sees Code
The pipeline's job is to make it impossible to deploy code that fails tests, breaks types, or violates security policy. Not difficult. Impossible. The word choice is intentional because "difficult" invites workarounds — and a quality gate with a workaround is just a slow speed bump on the road to production.
A well-structured gate sequence for an edge or serverless CI pipeline runs in this order: lint and type-checking first, because they are the fastest feedback and catch many issues in under a minute; unit and integration tests next, with external dependencies mocked; then the build step, which produces the deployable artifact; then a security scan covering dependency audits and secrets detection. A leaked API key in a preview URL is a production incident, not a preview incident. Only after the security scan does the pipeline deploy to the preview environment, followed by smoke tests against the live preview URL confirming the deployment is serving correctly.
The dependency structure of these steps matters. Lint, type-checking, and unit tests can run in parallel. The build step should be gated on all three passing. The preview deploy should be gated on a successful build. Structuring the directed acyclic graph correctly reduces total pipeline wall-clock time, which matters because slow pipelines get worked around.
It is also worth noting an architectural difference between edge platforms that is directly relevant to how teams think about pipeline feedback. Deploying a Cloudflare Worker propagates globally in seconds with a single command, because the Worker is pushed to all edge locations simultaneously rather than uploaded to a single origin region and propagated outward. Lambda@Edge operates differently: after uploading to us-east-1, propagation to all edge locations can take 15 to 30 minutes (source needed). That difference shapes how aggressive a team can be about deploying frequently and rolling back quickly.
One additional gate worth naming explicitly for teams running infrastructure-as-code alongside their application deployments: policy-as-code checks on infrastructure plan output can block changes that violate cost or security rules before they reach the apply step. That gate belongs in the pipeline, not in a post-deployment audit.
What does not belong in the automatic CI pipeline path: database migrations, secret rotation, and any durable-state change. These warrant explicitly triggered, manually approved jobs, separated from the pipeline that runs on every push.
Promoting Changes from Preview to Production Without Redeploying from Source
Here is the mistake that even disciplined teams make: when a pull request merges to main, the CI pipeline runs again on the merged commit and produces a new build. That new build has not been through the exact test run that validated the preview artifact. Environment-specific differences, dependency resolution at build time, and timing-sensitive test behavior can all introduce new failures silently. The build that passed all the gates and the build that gets deployed to production are different builds.
The correct model promotes the tested artifact, not the source. The artifact produced during the preview pipeline, whether a container image digest, a Workers bundle hash, or a Lambda deployment package, gets tagged and stored. The production deploy step retrieves that artifact and promotes it. It does not rebuild.
Progressive Delivery at the Promotion Step
Promotion to production does not have to be atomic. Canary routing sends a small fraction of production traffic to the new version before full rollout, allowing automated analysis of error rates, latency, and custom business metrics against a defined confidence window. If analysis passes, full rollout proceeds. If it fails, the routing reverts to the previous artifact automatically. This is a pipeline configuration change, not an infrastructure change, on platforms that support traffic splitting natively.
Blue/green deployment is the simpler variant: maintain two production slots and switch routing atomically when confidence is established. Rollback is a routing change, not a redeploy.
For stateful changes, including new Durable Object schemas or modified DynamoDB table shapes, promotion must include a migration step that executes before traffic shifts. The pipeline gates on migration success before flipping routing. Skipping this gate is how teams end up with a new version writing state the old version cannot read, which turns a routine deploy into a data-integrity incident.
Every production deploy should tag the exact commit SHA in Git. Not a branch name. A SHA. The artifact, the source, and the deployed version should be permanently and unambiguously linked.
Rollback as a First-Class Workflow Operation, Not an Emergency Improvisation
Teams that treat rollback as an emergency procedure will hesitate to execute it when they should. That hesitation turns a two-minute recovery into a twenty-minute incident. Rollback should be as routine as deploy, rehearsed as frequently as deploy, and documented as clearly as deploy.
For stateless edge and serverless changes, fast rollback is a matter of redeploying the previously tagged artifact. Not a Git revert commit, not a new build from an earlier branch state: the artifact that was last known-good in production, retrieved from the same artifact store used during promotion. On edge platforms that propagate globally in seconds, this recovery is nearly instantaneous. On platforms with longer propagation windows, the propagation time is the effective incident duration floor, which is why knowing your platform's behavior matters before you're in an incident, not during one.
The Limits of Rollback
Rollback cannot undo a schema migration that has already run against a production database. It also cannot undo durable state written by the new version in a format the old version cannot parse. It cannot reverse external API calls with side effects that have already executed. These are not edge cases; they are the reason rollback strategy must be considered at design time for stateful changes, not at incident time.
When rollback is unsafe, the forward-fix path becomes the incident response. That path should be practiced and documented: a minimal patch on the same artifact lineage, with the same pipeline gates compressed to their fastest safe execution. Every team I've seen practice forward-fix drills has meaningfully reduced incident duration compared to teams that discover the process for the first time during an outage.
The rollback and forward-fix procedures should live as runbooks in the repository, version-controlled alongside the code they apply to, referenced from the pipeline's README. A rollback procedure that lives in a wiki page last edited fourteen months ago is not a reliable rollback procedure.
Handling Secrets, Environment Variables, and Per-Environment Configuration Across the Workflow
The failure mode has three common expressions. Secrets committed to the repository in plaintext. Secrets copied between environments manually, producing silent drift. Secrets hardcoded into application code by developers who found the official secret-injection path too slow. Each of these is a different category of incident, and all three are preventable with the same structural intervention: secrets never live in Git.
At the pipeline level, CI platform secrets hold credentials that the pipeline itself needs, such as deploy tokens and registry credentials. At the application runtime level, secrets are injected from the platform's secret store per environment, scoped to the deployment target that actually needs them. Preview environments receive sandbox credentials. Production secrets are scoped to the production deployment target, and the CI pipeline should not have read access to production secrets at build time, only the deploy step that requires them and only in the moment it requires them.
Configuration drift between environments is the quieter failure. When preview and production environment variables diverge silently, the preview is testing a different application than what gets deployed. Periodic automated drift detection against a declared environment schema catches this before it causes a production incident that everyone traces back to a variable that was updated in production six weeks ago and never propagated to the preview configuration.
Secret rotation should be a non-event. Update the value in the platform's secret store, trigger a redeploy or rely on the platform's hot-reload capability where it exists. The pipeline should require no code changes to rotate a secret. If it does, the secret is coupled to the code in a way that will eventually produce a rotation delay during a security incident.
What the Workflow Looks Like End-to-End for a Team Operating at Scale
A representative deploy cycle for a mature edge or serverless team looks like this. A developer opens a pull request from a feature branch. CI runs lint, type-checking, and unit tests in parallel. A successful build produces a tagged artifact. A security scan validates the artifact. The artifact deploys to a preview environment. Smoke tests confirm the preview is live and serving correctly. The developer requests review.
A reviewer approves. The merge to main triggers promotion of the same artifact, not a new build. Canary routing sends a small fraction of production traffic to the new version. Automated analysis runs against production metrics for a defined window. Full rollout executes if analysis passes; automatic rollback to the previous artifact executes if it fails. The merge commit is tagged in Git with the artifact digest and deploy timestamp.
For a multi-service edge application running under the multi-repo pattern, each service's CI pipeline runs independently. A validated artifact opens a pull request to the central GitOps repository, bumping the service's version in the lock file. That pull request is the promotion event: it carries the CI result, the artifact reference, and the reviewer approval. Nothing deploys to production without passing through the lock-file PR gate.
This is the part of the workflow where platform choice becomes an operational reality. Cloudflare Pages connects a Git repository directly to the platform so that each push triggers a build and deploy, and Workers deploy globally in seconds rather than propagating region by region, which makes the canary-and-rollback cycle practically fast enough to use routinely rather than reserving it for high-stakes releases.
The workflow described here is not aspirational. Every team I know running it does not necessarily have a smaller engineering organization or a more favorable deployment target than teams still fighting their pipelines. They have a clean mapping between repository state and deployed state, pipelines that enforce quality gates rather than hoping developers remember them, and rollback procedures that get exercised on a schedule rather than discovered during incidents. The overhead that most teams treat as the unavoidable cost of modern infrastructure is, in many cases, process debt that the repository structure was never designed to eliminate.
