Platform
Turn coding agents into a delivery system.
Give coding agents shared context, coordinated execution, verification, and deployment workflows to take software from specification to production.
Work it out in a session first
A session reads your repositories and answers questions. When you know what you want, it writes a spec, and converting the spec puts it in your Tasks backlog.
From context to delivery
Understand the system. Plan the work. Put agents to work.
01 · Context
Start with a shared picture of your systems
Map repositories, services, and environments so agents begin with the relevant architecture. Review uncertain mappings and carry confirmed context into future work.
How shared context worksService → repo
- checkout-apiacme/checkouthigh
- billing-workeracme/billinghigh
- notify-svcacme/platform?low
Low-confidence mappings wait for a human to confirm them and are then reused across future work.
Illustrative product workflow.
02 · Plan
Agree on the specification before building
Use an Assistant session to explore the relevant code and define the goal, acceptance criteria, and exclusions. Turn the agreed specification into a task when you are ready to implement it.
Sessions and specificationsGoal
Move session auth onto rotating refresh tokens without logging anyone out.
Acceptance criteria
- Existing sessions stay signed in through the cutover
- Refresh tokens rotate on every use
- Rate limit is enforced per user, not per IP
Out of scope
SSO, password reset emails.
Illustrative product workflow.
03 · Execute
Follow the work through your team’s workflow
Choose the agent and model, then track implementation across your repositories. Tasks run in isolated environments and open pull requests for review. Verification and deployment follow your configured workflow and approval policies.
How Tasks workRotate refresh tokens
Drop legacy /v1 routes
Add SBOM to release
Node 18 → 20, all services
Fix flaky checkout test
Cache invalidation bug
Every card runs in an isolated container in your cloud and ends as a pull request you review.
Illustrative product workflow.
Your next project starts with more context.
The shared understanding of repositories, services, and environments carries into later work. Review and update it as your systems change, so each project builds on what your team has already established.
What it ships
Deploys run in your cloud, with no YAML to write. The build command, port, and health check are read from your repository.
Static sites
React, Next.js, Vue, Astro, and others, with HTTPS, a global CDN, cache invalidation, and rollbacks.
Web services
Go, Node.js, Python, Ruby, and Rust, with auto-scaling, health checks, and zero-downtime rollouts.
Environments
Dev, staging, and production, each in its own AWS account if you want them separated that way.
Custom domains and headers
Bring your domain. Certificates, CDN, and load balancing are wired for you; response headers are yours to set.
Logs and alerts
Build logs and application logs in the dashboard, with deploy alerts in Slack.
Control
Autonomy you grant, not autonomy you inherit
Agents get exactly the scope you give them and nothing else. Production approval policies let your team control release decisions, and the record of who allowed what stays queryable afterwards.
Role-based access controlsApproval gates
When an action requires approval under your configured policy, an authorized reviewer can approve or reject it before execution.
Roles for people and agents
Scope what each teammate and each MCP token can deploy, read, or approve. Share individual environments and deployments rather than the whole org.
An activity trail
Which agent ran, on what, with which model, what it changed, who approved the deploy, and when.
Your models, your keys
Bring your own provider key, or connect a Claude Code subscription. Plan with one model and build with another, and point the work at a better one when it ships.
Architecture
Control plane ours, data plane yours
Control plane
Runs on our AWS. Handles user management, scheduling the jobs your runner executes, billing, and the public API. It sees job state, logs, and metadata.
Data plane, in your cloud
The runner lives in your AWS account and does the actual work: checking out code, building, deploying, creating previews, and running coding agents in isolated containers. It needs a private subnet and an outbound HTTPS connection, nothing inbound.
Execution in your cloud
The runner checks out code and executes jobs in your cloud. Job state, logs, and metadata flow back over TLS. Model requests use your configured AI provider.
The runner is open source
The component that touches your infrastructure is public. Audit it, fork it, or build it yourself.
Revoke access anytime
You control runner permissions in your cloud account. Review those permissions, team access, and provider credentials when changing or ending access.
Already have an agent?
Drive it from the agent you already use
Deployment.io exposes a native MCP server, so Claude Code, Cursor, Windsurf, Copilot, Codex, or Gemini CLI can call real deploy actions rather than describing them. There is an open-source skill for agents that support one. Scope what each MCP token is allowed to do, the same way you scope a teammate.
Connect a repository and run one Task
The free tier is enough to see the whole loop: context, a session, a Task, and a deploy that waits for you.
Want us to handle delivery? How we work.