Agentic Develop
Bring a repo in and put agents on it, without deploying it
Not every repo is ready to run. Maybe it has no Dockerfile yet, or you just want an agent to work through it first. Agentic Develop brings the code into Rock8Cloud so agents can start on it, and leaves putting it live to you.
The rule is simple: a repository added with Agentic Develop is never deployed, not even if it has a Dockerfile. It stays that way until you deploy it yourself.
Starting
From the dashboard, the Your Next Project card opens the start page with two choices:
- Deploy and Develop - build it, put it live, and work on it with agents. This is the original flow.
- Agentic Develop - bring the code in and put agents on it.
Agentic Develop offers two sources:
- a GitHub repository you already have
- a blueprint, which forks the template repos into your GitHub
Databases, Dragonfly and S3 storage are not offered here. They have no code for an agent to work on, so you add them from inside the project when you need them.
The last step asks only for the URL, the project name and the service name. Branch, Dockerfile path, port, dependency scanning and environment variables are not shown, because none of them is a decision worth making before an agent has touched the code. Rock8Cloud uses your repo's default branch, and if the repo already has a Dockerfile it reads the path and port from it to prefill the build settings.
You can change any of it later in Deployments → Build settings, and environment variables are on the service page whenever you need them.
What Happens to Your Repo
| What you add | What Rock8Cloud does |
|---|---|
| Any GitHub repository | Creates the service and stops there. Nothing is built, no pods run, and its Deploy on Push workflow is turned off |
| A blueprint | Deploys it in full, same as Deploy and Develop |
A service added this way shows an empty Deployments tab. Nothing is built and no pods run for it, so it burns no build minutes. Pushes do not change that, including pull requests your agents open and you merge. Its allocation does still count against your plan's resource pool from the moment it is created, so sleep, shrink or delete one you are no longer working on. See Plans and usage.
Blueprints always deploy in full. A blueprint ships with working Dockerfiles, so picking one under Agentic Develop provisions everything that blueprint defines - its code, and whatever database or storage slots it comes with - exactly as Deploy and Develop would. Some are code only, such as Vue. You still get the agents, you just also get a running stack.
Working on It
Everything that needs only the repository works right away:
- Agents - coding and research sessions in a cloud sandbox. A coder session edits a checkout, pushes a branch and opens a pull request, exactly as it does on a deployed service.
- Custom agents and agent workflows
- Code reviews on pull requests
- Instructions - the standing rules your agents follow on this service
- Environment variables and build settings, so the first deploy is right when it comes
Going Live
Nothing deploys on its own. When the service is ready to run, you choose how it goes live. Both need a Dockerfile in the repo, so ask an agent to add one first if it is missing.
- Deploy once - press Manual deploy on the service page. This builds and deploys the service's branch. Pushes after that still do not deploy.
- Deploy on every push - open the service's Workflows tab and turn on the Deploy on Push workflow. From then on the service behaves like any other: each push to the default branch deploys it. See Workflows.
Most people do both: a manual deploy to go live now, and Deploy on Push so the next merge follows.
Once Deploy on Push is on, a push can still be skipped if your pool has no room left. It is audited in Settings > Audit logs as Auto-deploy skipped with the reason pod-limit, and you get a notification for it. Freeing capacity does not deploy it by itself, so sleep or shrink another service and then push again or use Manual deploy. See Plans and usage.
From Your Editor
If your agent is connected to the MCP server, you never need this screen. Ask it to add the repository without deploying it, or run the agentic_develop prompt, and it does the same thing: creates the project and service with autoDeploy: false, leaves the service idle, and starts working on the code.
When you are connected, the start page shows a prompt you can copy straight into your agent. It follows whatever you are looking at, so picking Blueprints or a specific blueprint rewrites it to match.
The MCP flow is not a separate feature. create_repo_service never deploys anything on its own, and autoDeploy: false creates the service with Deploy on Push turned off, exactly like the dashboard. Going live works the same way too.
FAQ
Does a waiting service cost me anything? No CPU or memory is actually consumed, because nothing is running, and no build minutes are spent. Its allocation is still reserved in your pool though, the same as any other service, so a pool that is full will stay full until you sleep, shrink or delete something. Agent runs consume AI budget as they do anywhere else.
My repo already has a Dockerfile. Why did it not deploy? Agentic Develop never deploys a repository, whether it has a Dockerfile or not. Use Manual deploy on the service page to go live, and turn on Deploy on Push in the Workflows tab if you want pushes to deploy it. If you wanted it live from the start, use Deploy and Develop instead.
An agent added a Dockerfile and I merged it. Why is nothing running? Deploy on Push is off for services added with Agentic Develop, so merges do not deploy. See Going Live.
Can I have some services deployed and others waiting in the same project? Yes. Each service has its own workflows, so turning on Deploy on Push for one does not affect the others.
What about the AI Dockerfile generator? That lives in Deploy and Develop, where a missing Dockerfile is a problem to solve up front. In Agentic Develop, writing the Dockerfile is your agent's job.