# From repo URL to production: a tour of Hydron's deployment pipeline > How Hydron turns a paste-in Git URL into a live application running on a dedicated server — three AI-driven planning stages, one orchestrated execution run, and what stays under your control. If you've used Hydron, you've seen the part above the waterline: paste a Git URL, answer a few clarifying questions in chat, and a few minutes later a fresh dedicated server is serving your app. This post is about the part below the waterline — the planning stages that the AI walks through before anything runs, the execution run that actually puts your app on a box, and where the boundaries between *AI judgment* and *your approval* sit. It's a long post. Skim the [Big picture](#the-big-picture) if you want to jump straight to the structure. ## Why this matters There's a real tradeoff in how you deploy in 2026. Pick a cloud or serverless platform and you trade away cost and control for an effortless `git push`. Pick a dedicated server and you get an order-of-magnitude better price-per-core plus full root access, but you're suddenly responsible for installing Docker, hardening SSH, configuring a reverse proxy, wiring SSL, watching disk space, and rebuilding all of it from scratch the next time you spin up a new box. That second path is where dedicated servers became "for ops people only." It's not that the hardware is hard — it's that the dozens of small, error-prone decisions in between are hard. Pick the wrong base image and your container won't run. Forget a firewall rule and you're locked out of a server you just paid for. Get the Nginx config slightly wrong and HTTPS won't terminate. Hydron's bet is that the dozens of small decisions are exactly the kind of work an AI is now genuinely good at. **You bring a repo URL. The AI handles the analysis, the planning, the commands, the recovery when something fails — and you get a real dedicated server you can SSH into.** This post is a tour of what that looks like end to end. > [!NOTE] > This is a high-level walkthrough. If you want to actually deploy something while reading, open the [Quick Start](/docs/quick-start) in a second tab — it has the matching screenshots and click-by-click steps. ## The big picture A deployment in Hydron is two things stacked together: - **Three planning stages.** Each one is AI-driven, each one produces a reviewable artifact you can edit in chat before approving. Planning is where the decisions are made — what to deploy, on what hardware, with what setup steps — and it all happens before a single server is touched. - **One execution run.** Once you approve the plans, a single orchestrated run goes from "no server exists" to "your app is serving traffic," with the AI staying in the loop to handle failures along the way. | | Stage | What it produces | Who decides | |---|---|---|---| | 1 | Source connection | A reference to your code | You | | 2 | Code analysis | Detected services, dependencies, Dockerfiles | AI proposes, you confirm | | 3 | Infrastructure plan | Server tiers + which services live where | AI proposes, you approve | | 4 | Provisioning plan | Per-server commands, configs, extra env vars | AI proposes, you approve | | 5 | The run | A live, healthy deployment | AI executes, you watch | The split between the three planning stages is deliberate. Each one answers a different question, and each one's output is the next one's input — so when something needs adjusting, you change it at the right altitude instead of starting over. --- ## Stage 1: Source connection You start by telling Hydron what to deploy. There are three input methods: - **Git repository** — GitHub, GitLab, Bitbucket, or any reachable Git URL. Hydron clones a shallow checkout to read the file tree. - **Docker image** — A reference to an image that's already built (e.g., `ghcr.io/yourorg/api:v1.4.2`). With a pre-built image, code analysis is skipped — the image is treated as a sealed unit and the next planning stage goes straight to infrastructure. - **Template** — A curated starter from the [template gallery](/templates). Templates are real open-source starter repositories — Node.js + Express, Next.js, Django, Rails, and so on — that Hydron knows how to deploy end to end. Picking a template is functionally a Git deployment using the template's repo as the source; the difference is the AI already knows the shape of what it's about to find. The first path is the most common, so we'll follow it for the rest of this post. ```bash # What "connecting a Git source" does, in spirit git clone --depth=1 --no-tags https://github.com/yourorg/yourapp.git ``` For private repos, you connect your GitHub / GitLab / Bitbucket account once and Hydron uses the OAuth grant to clone — no need to paste a personal access token into a form. ## Stage 2: Code analysis This is the first stage where the AI does real work. The analyzer's job is to look at your repository and produce a structured picture of what's in it: - **Services** — discrete deployable units. A monorepo with an API server, a frontend, and a worker becomes three services. A single Express app becomes one. - **Languages and frameworks** — Node.js + TypeScript, Python + Django, Ruby on Rails, Go, and so on, with the runtime version it should be built against. - **External dependencies your code expects** — databases (Postgres, MySQL, Mongo), caches and brokers (Redis, RabbitMQ), queues, and the external APIs / SaaS integrations your code calls out to (Stripe, S3, an OAuth provider). - **Environment variables** — extracted from `.env.example`, `process.env.*` references, framework conventions, and your README. Each variable gets a flag for whether it looks like a secret, whether it has a sensible default, and whether you'll need to provide it yourself. - **Build and start commands** — what to run to compile or build the project, and what to run to start the service. - **Application Dockerfiles** — if your repo already has a Dockerfile, the analyzer reuses it as-is. If it doesn't, the AI generates one tuned to your stack. Either way, the Dockerfile lands in your analysis as an editable artifact you can read and adjust, not a black-box internal template. ### What the analyzer reads ```text Repository tree ├─ package.json ← framework, scripts, deps ├─ Dockerfile ← reused if present, generated if not ├─ docker-compose.yml ← multi-service hints ├─ .env.example ← env var schema ├─ src/ │ └─ index.{ts,js,py,go} ← entrypoints, port bindings, route handlers └─ README.md ← human-written notes about deps and config ``` The analyzer reads files in a priority order — manifests first (`package.json`, `pyproject.toml`, `Gemfile`, `pom.xml`, `go.mod`), then the entrypoints those manifests declare, then anything referenced by those entrypoints. It does not crawl every file in a 20k-file monorepo token by token; for big repos that would be slow and expensive, and most of the answer is in the first hundred files anyway. ### Output The output is a structured analysis object that gets rendered as a card in the chat. Every field is editable: rename a service, change a runtime version, add a missing dependency, drop a service you don't want deployed. When you make a change, the next stage replans against the new analysis. > [!IMPORTANT] > The detected dependencies — databases, queues, brokers — feed directly into the next two stages. If the analyzer thinks your app needs Postgres, the infrastructure plan will place a Postgres service somewhere, and the provisioning plan will generate the Dockerfile and config to bring it up. So if a dependency was misdetected, fix it here, not later. ## Stage 3: Infrastructure plan Now the AI has a list of services. The infrastructure plan answers two questions: 1. **What servers should we use?** Picking from the available tiers — CPU cores, RAM, disk, datacenter — based on the workload size, geographic preference, and any budget you've set. 2. **Which services live on which server?** A small project usually ends up on a single box; a heavier workload might land the API on one server and the database on another so they don't compete for memory. Here's a simplified shape of what comes back: ```yaml recommended_servers: - tier: KS-LE-B spec: 4 cores · 16 GB RAM · 500 GB SSD region: Frankfurt, DE assigned_services: - api # detected backend - postgres # detected dependency - web # detected frontend rationale: > Single-server placement keeps internal latency low for the API↔Postgres path. The detected workload (3 services, low-medium traffic) fits comfortably within the tier's memory headroom. ``` The plan is generated as a single artifact, then handed back to you for review. You can ask the AI to change anything in chat ("split Postgres onto its own server", "use a server in the US instead of Frankfurt", "go one tier smaller") and it regenerates the plan; you re-approve the new version. > [!TIP] > The infrastructure plan does not specify the *commands* to set those servers up — only which servers to buy and what runs on each. The "how" comes next. ## Stage 4: Provisioning plan generation Once you've approved a set of servers and an assignment, the AI generates a per-server **provisioning plan** — a concrete sequence of shell commands, configuration files, and deployment steps that will turn a freshly-purchased blank server into one that's ready to receive your app. A provisioning plan contains: - **Setup steps** for each server: installing Docker, configuring the firewall, setting up SSH, preparing volumes, wiring a reverse proxy, requesting SSL certificates from Let's Encrypt. - **Non-application Dockerfiles** for services like databases, caches, and message queues that came out of code analysis but didn't have their own Dockerfile (your Postgres service isn't in your repo; the AI writes the Dockerfile for it here). - **Build configuration** — how each application image will be built on the server, including any build args and cache configuration. - **Deployment configuration** — start order, internal networking, healthcheck wiring. - **Additional environment variables** — beyond what code analysis found, the provisioning plan can introduce values that only make sense at deploy time: a generated database password that needs to flow into both the Postgres container and the API container that talks to it, a JWT signing secret created on the spot, runtime-computed values like internal hostnames. - **Post-deployment verification steps** — health probes and smoke checks to confirm everything came up correctly. Like the previous stages, the provisioning plan is editable. You can read every command before any of them runs, ask the AI to swap a base image, tighten a firewall rule, or change a port binding. Nothing has touched a server yet. ```text Provisioning plan → ks-le-b-fra-04 ┌────────────────────────────────────────────────────────┐ │ 1. Update package index & install base utilities │ │ 2. Install Docker engine + compose plugin │ │ 3. Configure UFW: deny incoming, allow 22/80/443 │ │ 4. Create application user with restricted shell │ │ 5. Set up internal Docker network │ │ 6. Build images: api, web │ │ 7. Pull and configure: postgres │ │ 8. Start services in dependency order │ │ 9. Configure reverse proxy + request SSL │ │ 10. Run post-deploy probes │ └────────────────────────────────────────────────────────┘ ``` > [!IMPORTANT] > The split between code analysis and provisioning plan generation is the key to understanding where each Dockerfile comes from. **Application Dockerfiles** — the ones for code you wrote — come from code analysis. **Non-application Dockerfiles** — Postgres, Redis, Nginx, sidecars — come from provisioning plan generation. That matters because if you edit your app's Dockerfile, you do it at the analysis stage; if you change how Postgres is configured, you do it at the provisioning stage. ## Stage 5: The run You've approved the three plans. Time to actually deploy. The execution run walks through a fixed sequence of phases — each one streams its logs back into the chat in real time. ### Purchase The AI places the actual order for the servers in the plan. This is the first moment money is spent on hardware. ### Availability A dedicated server isn't instant — once an order is placed, it takes minutes for the box to be racked, imaged, and assigned an IP. Hydron polls until the server is reachable, then moves on. ### Domain Hydron generates a deployment URL for you on its default domain. Every project gets a unique subdomain in the form `your-project-.hydron.space` — that's what comes back as your live URL when the deploy finishes. If you want to use your own domain, you point its DNS at the server's IP through your existing DNS provider — add an A record in Cloudflare, Route 53, your registrar, whatever you already use — set the custom domain on the project in Hydron, and the reverse-proxy and SSL config gets updated on the next deploy. ### OS install A fresh OS is installed on the server — Ubuntu, with the latest security patches. (If you've already provisioned this server with Hydron and are re-deploying, this step is skipped.) ### Provisioning This is the step where the **AI stays in the loop** — and it's also the step where most platforms simply give up if anything goes wrong. Provisioning runs the commands from your approved plan, but it doesn't run them as a blind shell script. Each command's output streams to the AI as well as to you. When something fails — a package mirror that's temporarily down, an apt repository that needs a new GPG key, a port that's unexpectedly occupied — the AI sees the actual stdout and stderr, decides on a fix, edits the next command, and retries. ```text Provisioning ks-le-b-fra-04 ┌─────────────────────────────────────────────────────────┐ │ [done] 1. Update package index │ │ [done] 2. Install Docker engine │ │ [done] 3. Configure UFW │ │ [done] 4. Create application user │ │ [done] 5. Set up internal Docker network │ │ [ai] 6. Build api image │ │ └─ ERROR: missing dependency openssl-dev │ │ └─ AI: adding apk add openssl-dev to step 6 │ │ └─ retrying... │ │ [done] 6. Build api image (after AI fix) │ │ [run] 7. Pull postgres │ │ [ ] 8. Start services │ │ [ ] 9. Configure reverse proxy + SSL │ │ [ ] 10. Post-deploy probes │ └─────────────────────────────────────────────────────────┘ ``` This is the difference between a deployment platform that *runs* a script and one that *understands* a script. The kind of papercut that would make you swear at a CI log at 2am — a missing system package, an OOM kill during a webpack build, a flaky package server — is the kind of thing the AI quietly handles, while showing you exactly what it did. ### Code deploy With the server in a good state, the AI deploys the application: - **Builds your application images** on the server, using the build config from the provisioning plan. - **Starts containers in dependency order** — databases first, then caches, then the services that talk to them. - **Wires up the reverse proxy** so external requests on `:443` route to the right internal container. - **Provisions SSL certificates** for your `hydron.space` subdomain (and your custom domain, if you've added one and pointed its DNS). ### Post deploy Final phase. The AI runs verification probes — actual HTTP requests against the public URL, not just container-level healthchecks — to confirm the whole path from internet → reverse proxy → container is alive. If a probe fails, the run is marked failed and the chat surfaces exactly which probe didn't pass. --- ## What the AI does — and what stays your call Across all of this, there are a few things the AI deliberately doesn't do on its own: 1. **Buy servers without your approval.** Provisioning a dedicated server is a real, recurring cost — so no server gets ordered until you've explicitly approved the infrastructure plan that includes it. AI planning itself uses credits and is part of the normal token cost, but hardware is its own gate. 2. **Mutate your repository.** The analyzer reads your code; it doesn't push back to it. If a generated Dockerfile or `.env.example` is something you want in your repo, you commit it yourself after Hydron shows it to you. 3. **Pick its own model tier.** Each project has a configured model — and Hydron uses the one you picked. It won't quietly switch you to a more expensive model to get a better answer. What the AI *does* do — and what makes the dedicated-server path feel less like ops work — is everything in between: reading your code, choosing servers, writing commands, fixing failures, and producing artifacts you can read and edit instead of opaque internals you can't see. ## Where to go from here If you want to actually try this: - **[Quick Start](/docs/quick-start)** — Click-by-click first deployment, with screenshots. - **[How It Works](/docs/how-it-works)** — Same pipeline tour as this post, but in reference-doc form (shorter, more diagrams). - **[Pricing](/pricing)** — What the AI costs at each model tier, what a server costs, and a capacity calculator built on real production token measurements. If you want to dig into a specific stage: - **[Code Analysis](/docs/code-analysis)** — How the AI reads your repo and what it returns. - **[Infrastructure Plans](/docs/infrastructure-plans)** — The plan format and how to edit it. - **[Server Provisioning](/docs/server-provisioning)** — The provisioning commands, the order, and the failure modes. - **[Domains & SSL](/docs/domains-ssl)** — Default subdomain, custom domain setup, certificate handling. - **[Deployment Runs](/docs/deployment-runs)** — The execution run, what each phase does, and how to read the live logs. And if you want to skip everything and just deploy something: - Visit [hydron.app](https://hydron.app), paste a Git URL, and watch the run unfold in real time.