Inspiration
I'm an IT student and I’m really interested in infrastructure, especially servers, networking, Linux VMs and Docker. I also run my own homelab.
While building and maintaining it, I kept running into the same workflow: something breaks, I search through documentation, ask an AI for help, copy a command into SSH, paste the error back into the chat and repeat until it works.
At the same time, I started using coding agents like Codex and Claude Code for my own projects. They can already do a lot of the coding work, but as soon as something needs to happen on a real server or in the cloud, I still have to copy and paste commands manually and make sure they do not break anything.
That made me wonder if a coding agent could manage infrastructure through MCP, without simply giving it full shell access and hoping for the best.
The name Drydock comes from the place where ships are built, repaired and tested before they go back into the water. The idea is similar for infrastructure: before a change reaches production, test it somewhere safe first.
What it does
Drydock lets coding agents inspect infrastructure and request changes through MCP.
When Codex wants to change something, it first creates a plan. Drydock checks that plan against its policies before anything can be applied.
Server changes are rehearsed inside an isolated Incus clone. Cloud firewall changes are previewed before they are sent to the provider.
Anything that changes real infrastructure requires human approval. The agent can inspect resources, create plans, test server changes and preview firewall changes, but it cannot approve its own work.
After I review and approve the plan in the web UI, the agent can continue and apply it. If a later step fails, Drydock can roll back the earlier steps.
How we built it
The main parts of Drydock are:
- An MCP server for coding agents
- A web UI for reviewing and approving plans
- A planning and policy system
- An Incus clone and rehearsal environment
- Hetzner firewall previews and execution
- A FastAPI backend with SQLite
- A React frontend built with Vite, Tailwind and shadcn/ui
Codex with GPT-5.6 built most of the project, including the MCP server, web UI, cloning flow, rehearsal system and executor.
When I reached my Codex usage limits, I used Claude Code with Opus 4.8 to help with polishing, testing and improving the approval workflow.
Challenges we ran into
The hardest part was working with Incus.
Many Incus operations are asynchronous, and sometimes the wait endpoint did not return what I expected. Rehearsals would fail with unclear errors, and it was difficult to tell whether the problem came from Incus, my own code or a tool call made by the agent.
I also ran into a timeout bug where an outer cancellation happened before the Incus operation had enough time to finish. This made slower scripts look like they had crashed even when the underlying operation was still running.
Another important issue was approval security. At one point, an agent using the MCP token could also approve its own plan. That defeated the whole purpose of Drydock.
I fixed this by separating the credentials. The coding agent uses one token, while the human console uses another. The agent cannot access the approval console or approve its own plans anymore.
One part that is still not fully handled by Drydock is publishing services to the internet. Drydock can change the server and the Hetzner firewall, but the host firewall and port forwarding into the container are currently configured by provisioning scripts.
Accomplishments that we're proud of
The feature I am most proud of is the rehearsal system.
It takes a snapshot of a real host, creates a clone on an isolated network, runs the exact proposed change there and deletes the clone afterwards.
If an nginx configuration is broken, it breaks inside the clone instead of in production.
I am also proud that approval is actually enforced by the backend. It is not just a button in the UI, and the agent cannot bypass it by changing its prompt or asking differently.
What we learned
One thing I learned is that working with real infrastructure is still slow when every command has to be copied from an agent into SSH manually.
That is also one of the main reasons I want to continue working on Drydock.
Vite and shadcn/ui worked very well for quickly building the approval interface.
The biggest lesson was that safety cannot live only inside a prompt. It has to be enforced by the system itself through policies, testing, approval, verification and rollback.
Codex worked very well overall, but I also ran into cases where sessions became corrupted or stopped early, so I could not complete everything in one continuous session.
What's next for Drydock
After the hackathon, I want to let users connect their own cloud accounts and servers.
I also want to add proper authentication, support more cloud providers and make the project easier to self-host.
The long-term idea is something similar to database MCP tools, but for servers, Docker, networking and temporary test environments.
Demo
The demo shows Codex using Drydock to publish a second nginx website on "web-01`" over port "8443", with access restricted to my IP address.
The plan also includes adding the required Hetzner firewall rule.
Drydock creates the plan, rehearses the server change in an isolated Incus clone, previews the firewall change and waits for my approval.
After I approve the plan in the web UI, Drydock applies the changes and verifies the result.
The demo uses real Incus containers, a real Hetzner firewall and real API calls. Drydock also has a sandbox mode for testing without real credentials, but the main demo uses the real integrations.
Important limitations
- Drydock currently supports Incus hosts and Hetzner Cloud firewalls.
- It cannot create or delete cloud servers yet.
- Host firewall rules and container port forwarding are still outside Drydock.
- It is currently single-user and does not have user accounts.
- Terraform, Ansible and Kubernetes are not supported yet.
Log in or sign up for Devpost to join the conversation.