Upsun Dispatch takes work from plan through code to review, then lands it in your GitHub or GitLab repository. What happens on merge is whatever already happens. Vercel, AWS, your own Kubernetes, or Upsun Cloud.
Planning in one place, coding in another, review in your Git provider, deploy in a pipeline. Nothing carries context across the handoffs, so each step starts over.
Platforms that cover planning through review usually want the deploy too, so how your team works with agents gets bundled with where the application runs.
Your environments, secrets, rollback path, and months of accumulated fixes live there. A new layer at the front of the chain shouldn't mean rebuilding the end of it.
Upsun Dispatch works through your repository. Work enters as an issue or a spec, agents code it in isolated sandboxes, and the change arrives as a pull request for a person to approve.
On merge, your repository does whatever it already did. The deploy path you rely on is untouched, because Upsun Dispatch is not in it.
Upsun Dispatch hands the finished change to your repository as a pull request. What happens after merge is whatever already happened.
An issue, a ticket, or a rough requirement becomes a plan an agent can act on. Scope, steps, and acceptance criteria written down before anything runs.
Agent steps execute in isolated, disposable sandboxes. Nothing in the workflow has access to your production environment or your deploy credentials.
The change arrives in your repository as a pull request or merge request. Your existing branch rules and required checks apply, and a person approves before it merges.
On merge, your pipeline runs. GitHub Actions, GitLab CI, a provider's Git integration, Argo CD, or Flux watching the repository. Upsun Dispatch does not participate in this step.
Your application runs where you chose to run it. How agents contribute to the codebase is a separate question, and answering it does not reopen the first one.
Different services, different targets, sometimes different providers. Upsun Dispatch works the same way across repositories that deploy to entirely different places.
If Argo CD, Flux or other tools already watches your repository, the merge is the deploy. Upsun Dispatch lands the change and your cluster picks it up on its own schedule.
Your own hardware is a deploy target like any other. If your repository can reach it today, nothing about that changes.
Pipelines that took months to get right keep working as they are. Upsun Dispatch adds plan, code and review in front of them, not a replacement for what happens after merge.
You can put Upsun Dispatch in front of your agents without touching hosting, and judge it on the first three steps alone. Nothing about the trial commits you to a migration.