# Hydron - AI-Powered Infrastructure Deployment Platform > Deploy and manage cloud infrastructure with AI-powered automation. Paste a repository URL, pick a template, or describe what you need. AI handles servers, Docker, domains, SSL — everything. For the complete documentation in a single file, see: https://hydron.app/llms-full.txt For a machine-readable docs index: https://hydron.app/docs/index.json ## Quick Facts - **Website**: https://hydron.app - **App URL**: https://app.hydron.app - **Documentation**: https://hydron.app/docs - **MCP Server**: `npx hydron-mcp` (Model Context Protocol) - **Free Credits**: Welcome bonus for new users, server costs separate - **Target Users**: Developers who want to deploy applications without DevOps expertise ## What Hydron Does Hydron is an AI-powered DevOps platform that automates the entire deployment lifecycle: 1. **Code Analysis**: AI analyzes your repository to detect frameworks, dependencies, and environment requirements 2. **Infrastructure Planning**: AI recommends optimal server configurations based on your application needs 3. **Automated Provisioning**: Dedicated servers are automatically provisioned 4. **Docker Configuration**: Automatic containerization with Docker and docker-compose 5. **Domain & SSL**: Automatic domain configuration and SSL certificate management via Let's Encrypt 6. **CI/CD Setup**: Automatic continuous deployment pipelines ## Supported Input Methods 1. **Git Repository URL**: Paste any public or private Git repository URL 2. **Docker Image**: Deploy from Docker Hub or any container registry 3. **Templates**: Choose from pre-built templates (Next.js, Express, FastAPI, Django, etc.) 4. **Natural Language**: Describe what you want to deploy ## Supported Technologies Hydron supports any framework or language including: - **Frontend**: React, Vue, Next.js, Nuxt, Svelte, SvelteKit, Astro, Gatsby - **Backend**: Express, NestJS, FastAPI, Django, Flask, Rails, Spring Boot - **Databases**: PostgreSQL, MySQL, MongoDB, Redis - **Languages**: JavaScript/TypeScript, Python, Ruby, Java, Go, PHP ## MCP (Model Context Protocol) Integration Hydron provides a comprehensive MCP server for AI agents to programmatically: ### Installation ```bash npx hydron-mcp ``` ### Environment Variables - `HYDRON_API_URL` - Base URL for Hydron backend API - `HYDRON_API_TOKEN` - Authentication token (obtain from app.hydron.app/settings) - `HYDRON_DEVOPS_URL` - DevOps orchestrator URL - `HYDRON_CODE_ANALYZER_URL` - Code analyzer service URL ### Available MCP Tools **Code Analysis:** - `analyze_repository` - Analyze a Git repository to detect stack and requirements - `get_analysis_status` - Check analysis progress - `get_analysis_result` - Get detailed analysis results **Infrastructure:** - `plan_infrastructure` - Generate infrastructure recommendations - `get_server_offers` - List available server offerings with pricing - `generate_provisioning_plan` - Create a detailed provisioning plan **Inventory Management:** - `list_servers` - List all managed servers - `get_server_details` - Get detailed server information including SSH access - `reboot_server` - Reboot a server - `adopt_server` - Bring an external server under Hydron management - `schedule_termination` - Schedule server termination **Deployment:** - `start_deployment` - Start a new deployment - `get_deployment_status` - Check deployment progress - `get_deployment_logs` - Stream deployment logs - `list_runs` - List deployment runs **Chat/Projects:** - `list_projects` - List all projects - `create_project` - Create a new project - `list_chats` - List deployment chats - `create_chat` - Start a new deployment conversation ## Pricing - **Welcome Bonus**: Free credits for new users - **AI Credits**: Credits-based pricing for AI features, top up as needed - **Server Costs**: Infrastructure billed based on provisioned servers ## Key Differentiators 1. **Real Servers**: Unlike serverless platforms, apps run on dedicated servers with full SSH access 2. **No Vendor Lock-in**: Export your configuration and migrate anytime 3. **Full Control**: SSH access to your servers, full Docker control 4. **AI-First**: Natural language interface for deployment and management ## Getting Started 1. Visit https://hydron.app 2. Click "Start Building Free" 3. Sign up and get free credits to start 4. Paste your repository URL or choose a template 5. AI analyzes and deploys your application ## API Access For programmatic access: 1. Create an account at https://app.hydron.app 2. Navigate to Settings > API Tokens 3. Generate an API token 4. Use with the MCP server or REST API ## Support - **Documentation**: https://hydron.app/docs - **Contact**: https://hydron.app/contact ## Documentation Pages Individual doc pages are available as clean markdown at `/docs/{slug}.md`. The documentation index page (lists all sections with links) is available as markdown at: - [Documentation Home](https://hydron.app/docs.md) - All sections and pages (For programmatic consumption, a JSON index is also available at https://hydron.app/docs/index.json — not a documentation page itself.) ### Getting Started - [Introduction](https://hydron.app/docs/introduction.md) - What is Hydron and how does it work - [Quick Start](https://hydron.app/docs/quick-start.md) - Deploy your first app in minutes - [Key Concepts](https://hydron.app/docs/concepts.md) - Core concepts: projects, services, chats, plans ### Deploying - [Deploy from Git](https://hydron.app/docs/deploy-from-git.md) - Deploy from GitHub, GitLab, Bitbucket, or any Git URL - [Deploy a Docker Image](https://hydron.app/docs/deploy-docker.md) - Deploy an existing Docker image to your servers - [Using Templates](https://hydron.app/docs/templates.md) - Quick-start with pre-configured templates ### Managing Your App - [Projects](https://hydron.app/docs/projects.md) - Create, organize, and manage your projects - [Services](https://hydron.app/docs/services.md) - Understanding and configuring services - [Environment Variables](https://hydron.app/docs/environment-variables.md) - Setting and managing environment variables - [Domains & SSL](https://hydron.app/docs/domains-ssl.md) - Custom domains and SSL certificates ### Infrastructure - [How It Works](https://hydron.app/docs/how-it-works.md) - The full deployment pipeline explained - [Code Analysis](https://hydron.app/docs/code-analysis.md) - How AI analyzes your codebase - [Infrastructure Plans](https://hydron.app/docs/infrastructure-plans.md) - Understanding generated infrastructure plans - [Server Provisioning](https://hydron.app/docs/server-provisioning.md) - How servers are provisioned and configured - [Server Inventory](https://hydron.app/docs/server-inventory.md) - Browsing and managing your dedicated servers - [Deployment Runs](https://hydron.app/docs/deployment-runs.md) - Monitoring and managing active deployments ### Account - [Account Setup](https://hydron.app/docs/account-setup.md) - Registration, login, and OAuth - [Security](https://hydron.app/docs/security.md) - Two-factor authentication and session management - [Billing & Credits](https://hydron.app/docs/billing.md) - Credit system, usage tracking, and subscriptions ## Roadmap Hydron publishes a public roadmap covering the next three months of development, organized as Now / Next / Later with no fake deadlines. A plain markdown version is available for agents at `/roadmap.md`. - Roadmap: https://hydron.app/roadmap - Roadmap (markdown): https://hydron.app/roadmap.md ## Blog Hydron publishes engineering deep dives and infrastructure write-ups on the blog. All posts are also available as plain markdown at `/blog/{slug}.md` and the blog index is at `/blog.md`. - Blog: https://hydron.app/blog - Blog (markdown index): https://hydron.app/blog.md - Blog (machine-readable index): https://hydron.app/blog/index.json - Blog (RSS feed): https://hydron.app/blog/rss.xml ### Articles - [From repo URL to production: a tour of Hydron's deployment pipeline](https://hydron.app/blog/from-repo-to-production-pipeline-tour.md) - How Hydron turns a paste-in Git URL into a live application on a dedicated server: three AI-driven planning stages, one orchestrated execution run, and what stays under your control. ## Links - Homepage: https://hydron.app - Application: https://app.hydron.app - Documentation: https://hydron.app/docs - Documentation (full text): https://hydron.app/llms-full.txt - Documentation (index): https://hydron.app/docs/index.json - Blog: https://hydron.app/blog - Blog (RSS): https://hydron.app/blog/rss.xml - Templates: https://hydron.app/templates - Roadmap: https://hydron.app/roadmap - About: https://hydron.app/about - Terms: https://hydron.app/terms - Privacy: https://hydron.app/privacy --- # Full Documentation Below is the complete Hydron documentation. Each section is separated by a horizontal rule. # Introduction Hydron is an AI-powered deployment platform that automates the entire process of getting your application from code to production. Instead of manually configuring servers, writing Dockerfiles, and setting up CI/CD pipelines, you describe what you need through a conversational chat interface and Hydron handles the rest. ## What is Hydron? Hydron is a **conversational deployment platform**. You interact with an AI assistant through a chat interface, and it: - **Analyzes your code** to detect frameworks, dependencies, and requirements - **Generates infrastructure plans** with the right servers and configurations - **Provisions dedicated servers** with Docker, networking, and security - **Builds and deploys** your application with proper health checks - **Configures domains and SSL** automatically Unlike traditional PaaS platforms that hide infrastructure behind abstractions, Hydron gives you **real dedicated servers with full SSH access**. There's no vendor lock-in — you own your infrastructure and can take it with you at any time. ## Who is Hydron for? Hydron is designed for: - **Developers** who want to ship fast without learning Kubernetes or cloud infrastructure - **Startups** that need production-ready deployments without a dedicated DevOps team - **Teams** that want automated, reproducible deployments with full server control - **Freelancers** deploying client projects who need quick, reliable infrastructure ## How it works The deployment process follows four steps: 1. **Connect** — Provide a Git repository URL, Docker image, or select a template 2. **Analyze** — AI scans your codebase to understand the technology stack, detect services, and identify requirements 3. **Plan** — An infrastructure plan is generated with optimal server configurations, Dockerfiles, and deployment strategies 4. **Deploy** — Servers are provisioned, your app is built and deployed, domains and SSL are configured All of this happens through a chat interface where you can review, modify, and approve each step.  ## Key features | Feature | Description | |---------|-------------| | **AI Chat Interface** | Conversational deployment — describe what you need in plain English | | **Code Analysis** | Automatic detection of frameworks, dependencies, and environment requirements | | **Infrastructure Planning** | AI-generated deployment plans with server specs and configurations | | **Dedicated Servers** | Real servers with full SSH access, not shared hosting | | **Docker-based** | Everything runs in Docker containers for consistency and isolation | | **SSL & Domains** | Automatic SSL certificate provisioning and domain configuration | | **Real-time Monitoring** | Live streaming logs and deployment progress tracking | | **Multiple Sources** | Deploy from Git (GitHub, GitLab, Bitbucket), Docker images, or templates |  ## What makes Hydron different Unlike traditional deployment platforms: - **Conversational, not form-based** — You chat with AI instead of filling out configuration forms. Describe your needs naturally and the AI figures out the infrastructure. - **You own your servers** — Full SSH access to dedicated servers. No proprietary runtimes or vendor lock-in. You can take your infrastructure and leave at any time. - **AI does the heavy lifting** — From code analysis to Dockerfile generation to server configuration, the AI handles the complexity so you don't have to. - **Real-time visibility** — Watch every step of the deployment process live with streaming logs and progress updates. ## Next steps Ready to get started? Head to the [Quick Start](/docs/quick-start) guide to deploy your first application, or learn about [Key Concepts](/docs/concepts) to understand how Hydron works under the hood. --- # Quick Start Deploy your first application with Hydron in just a few minutes. This guide walks you through the entire process from sign-up to a live deployment. ## Prerequisites Before you begin, you'll need: - A **Hydron account** — [Sign up for free](https://hydron.space/register) if you don't have one - A **Git repository** with your application code (GitHub, GitLab, Bitbucket, or any public URL) - Alternatively, a **Docker image** already pushed to a registry ## Step 1: Create a project After signing in, you'll land on the **Projects** dashboard. Click **New Project** to create your first project.  Give your project a name and select a type that best matches your application (Web App, Microservice, Static Site, etc.). The project type helps Hydron optimize its analysis and deployment strategy. ## Step 2: Start a chat Once your project is created, you'll be taken to the **chat interface**. This is where you interact with the AI assistant to deploy your application. You'll see a welcome screen with deployment options:  - **GitHub / GitLab / Bitbucket** — Connect your account and select a repository - **Public Git URL** — Paste any public repository URL - **Docker Image** — Provide a Docker image name and tag - **Templates** — Choose from pre-built deployment templates ## Step 3: Connect your code For this quick start, let's deploy from a Git URL. Click on **Public Git URL** and paste your repository URL, then click **Analyze Repository**. The AI will begin scanning your codebase. ## Step 4: Review the code analysis Hydron's AI analyzes your repository to detect: - **Frameworks and languages** (e.g., Node.js with Express, Python with Django) - **Services** within your project (API server, frontend, database, etc.) - **Dependencies** and their versions - **Environment variables** your app needs - **Existing Dockerfiles** or recommendations for new ones The analysis results appear in the chat and in the right sidebar panel. Review the detected services and make any adjustments if needed.  ## Step 5: Generate an infrastructure plan After the analysis, the AI generates an **infrastructure plan** tailored to your application. The plan includes: - **Server specifications** — CPU, RAM, storage, and datacenter location - **Docker configuration** — Dockerfiles for each service - **Networking** — Port mappings, domain configuration - **Environment variables** — Required variables with descriptions - **Health checks** — Endpoints and intervals for monitoring Review the plan in the **Infrastructure** tab on the right sidebar. You can ask the AI to modify any aspect — change server size, add or remove services, adjust environment variables.  ## Step 6: Approve and deploy When you're satisfied with the plan, approve it. The AI will: 1. **Provision the server** — Set up a dedicated server with your chosen specs 2. **Install Docker** and required software 3. **Build your application** using the configured Dockerfile 4. **Deploy containers** with proper networking and health checks 5. **Configure domains and SSL** — Set up your domain with automatic SSL certificates You can watch the entire process in real-time through the **Runs** tab on the right sidebar. Each step shows live logs and progress indicators.  ## Step 7: Your app is live Once deployment completes, your application is live and accessible. You'll receive: - **Your application URL** with SSL configured - **SSH access credentials** for direct server access - **Deployment logs** for debugging if needed ## What's next? Now that your first app is deployed, explore these guides: - [Key Concepts](/docs/concepts) — Understand projects, services, and plans in depth - [Environment Variables](/docs/environment-variables) — Configure secrets and settings - [Domains & SSL](/docs/domains-ssl) — Set up custom domains - [Server Inventory](/docs/server-inventory) — Manage your servers - [Deployment Runs](/docs/deployment-runs) — Monitor and troubleshoot deployments --- # Key Concepts Understanding Hydron's core concepts will help you make the most of the platform. This page explains the fundamental building blocks and how they fit together. ## Overview Hydron is organized around five core concepts: **Projects**, **Services**, **Chats**, **Infrastructure Plans**, and **Servers**. Each builds on the others to create a complete deployment workflow.  ## Projects A **Project** is the top-level container for everything related to a deployment. It groups together your services, conversations, infrastructure plans, and deployment history. **Key characteristics:** - Each project has a **name** and **type** (Web App, Microservice, Static Site, etc.) - Projects contain one or more **services** (your application components) - Projects have **chats** where you interact with the AI assistant - Each project tracks its own **infrastructure plans** and **deployment runs**  **Common patterns:** - **One project per application** — A full-stack app with frontend, backend, and database - **One project per environment** — Separate projects for staging and production - **One project per client** — Freelancers managing multiple client deployments ## Services A **Service** represents a deployable component within your project. Services are detected during code analysis or added manually. **Examples of services:** - An Express.js API server - A React frontend application - A PostgreSQL database - A Redis cache - A background worker process **Each service has:** - A **name** and **type** identifier - A **source** — Git repository, Docker image, or template - A **Dockerfile** — Existing or AI-generated - **Environment variables** — Configuration values the service needs - **Port mappings** — Which ports the service exposes - A **health check** — Endpoint and interval for monitoring Services can depend on each other. For example, your API server might depend on a database service. Hydron understands these relationships and configures networking accordingly. ## Chats The **Chat** is your primary interface for interacting with Hydron. Instead of filling out forms or writing configuration files, you describe what you need in natural language. **What you can do in a chat:** - Connect a repository and trigger code analysis - Ask the AI to generate or modify infrastructure plans - Review and approve deployment steps - Ask questions about your infrastructure - Request changes to server configurations - Troubleshoot deployment issues **How chats work:** - Each chat belongs to a project - Messages are streamed in real-time from the AI - The AI can trigger actions like code analysis, plan generation, and deployment - Action cards appear in the chat for reviewing and approving steps - Multiple chats can exist per project for different topics or deployment iterations ## Infrastructure Plans An **Infrastructure Plan** is the AI-generated blueprint for deploying your application. It specifies everything needed to go from code to a running production environment. **A plan includes:** | Component | Description | |-----------|-------------| | **Server specs** | CPU, RAM, storage, datacenter location | | **Dockerfiles** | Container configurations for each service | | **Environment variables** | Required configuration values | | **Port mappings** | Network ports for each service | | **Health checks** | Monitoring endpoints and intervals | | **Domain configuration** | Domain names and SSL settings | | **Post-deploy commands** | Scripts to run after deployment | **Plan lifecycle:** 1. **Generated** — AI creates the plan based on code analysis 2. **Reviewed** — You review the plan in the Infrastructure panel 3. **Modified** — Ask the AI to change any aspect 4. **Approved** — You approve the final plan 5. **Executed** — Servers are provisioned and app is deployed Plans become **stale** if you change services after the plan was created. Hydron will notify you and suggest regenerating the plan. ## Servers  Hydron deploys your applications to **dedicated servers** — real machines that you own and control. These are not shared hosting or serverless functions. **Server characteristics:** - **Dedicated hardware** — Your own CPU, RAM, and storage - **Full SSH access** — Connect directly via SSH with root access - **Docker-based** — Applications run in Docker containers - **Managed provisioning** — Hydron handles OS installation and configuration - **No vendor lock-in** — Your server, your data, your control **Server lifecycle:** 1. **Selected** — You choose a server specification from available options 2. **Provisioned** — OS is installed and Docker is configured 3. **Deployed** — Your application containers are running 4. **Monitored** — Health checks verify your app is running Servers are managed through the **Server Inventory**, where you can view details, add tags, link servers to projects, and monitor their status. ## Deployment Runs A **Run** represents a single execution of a deployment pipeline. Each time you deploy or redeploy, a new run is created. **A run tracks:** - **Provisioning steps** — Server setup commands and their status - **Build steps** — Docker image building progress - **Deploy steps** — Container deployment and health check results - **Logs** — Real-time streaming output from each step **Run statuses:** - **Started** — The run has been initiated - **In Progress** — Steps are actively executing - **Completed** — All steps finished successfully - **Failed** — One or more steps encountered an error - **Paused** — The run was manually paused - **Stopped** — The run was manually stopped You can pause, resume, or stop a run at any time. Failed runs show detailed error logs to help you troubleshoot. ## How everything connects Here's how a typical deployment flows through these concepts: 1. Create a **PROJECT** 2. Start a **CHAT** within the project 3. Connect your code — AI detects **SERVICES** 4. AI generates an **INFRASTRUCTURE PLAN** 5. You review and approve the plan 6. A **DEPLOYMENT RUN** provisions **SERVERS** 7. Your app is live on dedicated **SERVERS** Each concept builds on the previous one, and the AI assistant guides you through each step via the chat interface. ## Next steps - [Deploy from Git](/docs/deploy-from-git) — Walk through a complete deployment - [Projects](/docs/projects) — Learn how to organize and manage projects - [Infrastructure Plans](/docs/infrastructure-plans) — Understand plan details --- # Deploy from Git Hydron supports deploying applications directly from Git repositories. You can connect via GitHub, GitLab, Bitbucket, or any publicly accessible Git URL. ## Supported Git providers | Provider | Connection method | |----------|------------------| | **GitHub** | OAuth integration or public URL | | **GitLab** | OAuth integration or public URL | | **Bitbucket** | OAuth integration or public URL | | **Any Git host** | Public repository URL | ## Connecting via OAuth For private repositories, connect your Git provider account through OAuth. This gives Hydron secure, read-only access to your repositories. 1. In a new chat, click on your preferred provider (GitHub, GitLab, or Bitbucket) 2. You'll be redirected to authorize Hydron 3. Once connected, you'll see a list of your repositories 4. Select the repository you want to deploy OAuth connections are stored securely and can be managed from your **Account Settings**. ## Connecting via public URL For public repositories, you can paste the Git URL directly: 1. In a new chat, click **Public Git URL** 2. Enter the repository URL (e.g., `https://github.com/username/repo.git`) 3. Click **Analyze Repository** Hydron clones the repository and begins the code analysis process. ## What happens during code analysis After connecting your repository, Hydron's AI performs a comprehensive analysis:  The analysis detects: - **Programming languages** and their versions - **Frameworks** (Express, Django, Rails, Spring Boot, etc.) - **Package managers** and dependencies - **Services** within monorepos or multi-service projects - **Existing Dockerfiles** and their quality - **Environment variables** referenced in the code - **Entry points** and build commands ## Reviewing analysis results Analysis results appear both in the chat and in the **right sidebar** panel. For each detected service, you'll see: - Service name and detected type - Framework and language - Dockerfile status (existing or needs generation) - Required environment variables - Port configuration You can **accept** or **reject** individual services. Only accepted services will be included in the infrastructure plan. ## Selecting which services to deploy For monorepo or multi-service projects, Hydron detects all deployable components. You choose which ones to include in the **Services** tab in the right sidebar.  Uncheck any services you don't want to deploy. The infrastructure plan will only include the selected services. ## Dockerfile handling Hydron handles Dockerfiles in several ways: - **Existing Dockerfile detected** — Hydron uses your existing Dockerfile as-is, or suggests improvements - **No Dockerfile found** — The AI generates an optimized Dockerfile based on the detected framework - **Multiple Dockerfiles** — For multi-service repos, each service gets its own Dockerfile You can always edit the Dockerfile through the chat interface. Ask the AI to make changes like: - "Add a multi-stage build to reduce image size" - "Switch the base image to Alpine" - "Add a build cache layer for dependencies" ## After analysis Once you're satisfied with the analysis results: 1. Review and accept the detected services 2. Add any missing environment variables 3. The AI will offer to generate an infrastructure plan 4. Continue to [Infrastructure Plans](/docs/infrastructure-plans) to understand the next step ## Troubleshooting **Analysis taking too long?** Large repositories with many files may take longer to analyze. The AI prioritizes relevant files (source code, config files, Dockerfiles) and skips binary/media files. **Wrong framework detected?** Tell the AI in the chat: "This is actually a Next.js app, not a plain React app" — the AI will update its analysis. **Missing services?** Ask the AI to re-analyze specific directories: "Please also check the /services/auth directory for another service." **Private repository access issues?** Ensure your OAuth connection is active in Account Settings. For organization repos, you may need to grant Hydron access to the organization. --- # Deploy a Docker Image If you already have a Docker image built and pushed to a registry, Hydron can deploy it directly without analyzing source code. ## When to use Docker deployment Docker image deployment is ideal when you: - Already have a CI/CD pipeline that builds Docker images - Want to deploy a pre-built image from Docker Hub or a private registry - Are deploying a third-party application (databases, monitoring tools, etc.) - Have complex build processes handled outside of Hydron ## Connecting a Docker image 1. In a new chat, select **Existing Image** from the deployment options 2. Enter the image name and tag, along with any registry credentials  ## Supported registries Hydron can pull images from any Docker-compatible registry: | Registry | Example image reference | |----------|----------------------| | **Docker Hub** | `myuser/myapp:v1.0` | | **GitHub Container Registry** | `ghcr.io/org/myapp:latest` | | **GitLab Container Registry** | `registry.gitlab.com/org/myapp:latest` | | **AWS ECR** | `123456789.dkr.ecr.region.amazonaws.com/myapp:v1` | | **Google Artifact Registry** | `region-docker.pkg.dev/project/repo/myapp:v1` | | **Self-hosted** | `registry.example.com/myapp:latest` | For private registries, provide your authentication credentials when prompted. Credentials are encrypted and stored securely. ## How it works When deploying a Docker image, the process is simpler than a Git deployment since the build step is skipped. The AI plans your infrastructure, provisions the server, and pulls and deploys the container. The AI will ask you about: - **Port mappings** — Which ports does your container expose? - **Environment variables** — What configuration does the container need? - **Volumes** — Does the container need persistent storage? - **Resource requirements** — How much CPU and RAM does it need? - **Health checks** — How to verify the container is healthy? ## Environment variables You can provide environment variables when configuring the Docker deployment. These are injected into the container at runtime: Sensitive values are encrypted at rest and never exposed in logs. ## After deployment Once your Docker container is deployed, you can: - View running containers and their status - Access real-time logs - Restart or redeploy with a different image tag - Update environment variables - Scale resources ## Updating the image To deploy a new version of your image: 1. Push the updated image to your registry 2. In the project chat, ask: "Redeploy with the latest image" 3. Or specify a tag: "Deploy myapp:v2.0" Hydron pulls the new image and performs a rolling update with zero downtime when possible. --- # Using Templates Templates provide pre-configured deployment setups for common application stacks. They're the fastest way to get started with Hydron — select a template, customize a few settings, and deploy. ## How templates work A template includes: - **Pre-configured services** with optimized settings - **Dockerfiles** tuned for the specific stack - **Environment variable** definitions with sensible defaults - **Health check** configurations - **Recommended server** specifications When you choose a template, Hydron sets up everything automatically. You only need to provide your application-specific values (database passwords, API keys, etc.). ## Available template categories ### Web Applications | Template | Stack | Description | |----------|-------|-------------| | **Node.js + Express** | Node.js, Express, MongoDB | REST API with database | | **React + Node.js** | React, Express, PostgreSQL | Full-stack web application | | **Next.js** | Next.js, PostgreSQL | Server-rendered React application | | **Django** | Python, Django, PostgreSQL | Python web framework | | **Rails** | Ruby on Rails, PostgreSQL | Ruby web framework | | **Laravel** | PHP, Laravel, MySQL | PHP web framework | | **Spring Boot** | Java, Spring Boot, PostgreSQL | Java enterprise application | ### Static Sites | Template | Stack | Description | |----------|-------|-------------| | **React SPA** | React, Nginx | Single-page application with Nginx | | **Vue.js SPA** | Vue.js, Nginx | Vue.js application with Nginx | | **Static HTML** | HTML/CSS/JS, Nginx | Plain static files served by Nginx | ### Databases & Services | Template | Stack | Description | |----------|-------|-------------| | **PostgreSQL** | PostgreSQL 16 | Managed PostgreSQL database | | **MySQL** | MySQL 8 | Managed MySQL database | | **Redis** | Redis 7 | In-memory cache and message broker | | **MongoDB** | MongoDB 7 | Document database | ## Using a template 1. In a new chat, select **Templates** from the deployment options 2. Browse or search the template gallery 3. Select the template that matches your needs 4. Customize the configuration: - Application name - Environment variables - Server location preference 5. Review the generated infrastructure plan 6. Approve and deploy  ## Customizing templates Templates are starting points, not rigid configurations. After selecting a template, you can customize everything through the chat: - "Change the database to MySQL instead of PostgreSQL" - "Add a Redis cache to this stack" - "Use a larger server with 32GB RAM" - "Add an Nginx reverse proxy in front of the API" The AI will update the infrastructure plan to reflect your changes. ## Templates vs. Git deployment | Aspect | Templates | Git deployment | |--------|-----------|---------------| | **Speed** | Fastest — deploy in minutes | Requires code analysis first | | **Customization** | Pre-configured, then customizable | Fully analyzed from your code | | **Best for** | Standard stacks, quick prototypes | Custom applications | | **Code included** | Template starter code | Your existing codebase | You can start with a template and later switch to deploying your own code from Git by adding your repository as a service. --- # Projects Projects are the top-level organizational unit in Hydron. Every deployment, conversation, and infrastructure plan belongs to a project. ## Creating a project To create a new project: 1. Navigate to the **Projects** dashboard 2. Click **New Project** 3. Enter a project name 4. Select the project type ### Project types Choose the type that best matches your application: | Type | Best for | |------|----------| | **Web App** | Full-stack web applications (frontend + backend) | | **Microservice** | Individual API services or backend components | | **Static Site** | HTML/CSS/JS sites, SPAs, documentation | | **Kubernetes** | Container orchestration workloads | | **Data Analytics** | Data processing and analysis pipelines | | **ML Inference** | Machine learning model serving | | **Batch Worker** | Background job processors and task queues | | **Data Storage** | Databases and storage services | The project type helps the AI optimize its code analysis and infrastructure recommendations. ## Projects dashboard The Projects dashboard is your home screen after signing in. It provides several ways to browse and organize your projects.  ### View modes Switch between two view modes: - **Card view** — Visual cards showing project name, type, and status - **List view** — Compact list with more projects visible at once ### Sorting Sort your projects by: - **Last activity** — Most recently active projects first (default) - **Name** — Alphabetical order - **Creation date** — Newest projects first ### Searching Use the search bar to filter projects by name. The search updates in real-time as you type. ### Filtering Filter projects by their environment status to quickly find projects in a specific state. ## Favorites Mark frequently accessed projects as **favorites** by clicking the star icon. Favorited projects appear in a dedicated section at the top of the dashboard and in the sidebar for quick access. ## Project settings Access project settings by clicking the gear icon or navigating to **Settings** within a project.  Available settings include: ### General - **Name** — Rename your project - **Description** — Add a description for reference - **Type** — Change the project type ### Services - View and manage all services linked to the project - Add new services or remove existing ones - Configure service-specific settings ### AI Settings - **Model** — Choose the AI model for conversations - **System prompt** — Customize the AI's behavior for this project - **Temperature** — Adjust creativity vs. determinism ### Linked servers - View which servers from your inventory are linked to this project - Link or unlink servers ### Danger zone - **Delete project** — Permanently delete the project and all associated data ## Managing projects from the sidebar The left sidebar in the chat interface provides quick access to: - All your projects with favorites at the top - Recent chats within each project - Quick project switching without leaving the chat You can **rename** or **delete** projects directly from the sidebar context menu. ## Best practices - **One project per application** — Keep related services together in one project - **Use descriptive names** — "E-commerce API" is better than "Project 1" - **Favorite active projects** — Keep your current work easily accessible - **Archive completed work** — Delete projects you no longer need to keep the dashboard clean --- # Services A Service in Hydron represents a single deployable component of your application. Most projects have one or more services — for example, a web application might have an API service, a frontend service, and a database service. ## How services are created Services are created in two ways: 1. **Automatically detected** — When you connect a Git repository, the AI analyzes your code and detects services based on the project structure, entry points, and configuration files 2. **Manually added** — You can add services through the chat or project settings ## Service properties Each service has the following properties: | Property | Description | |----------|-------------| | **Name** | A unique identifier within the project (e.g., `api-server`, `frontend`) | | **Type** | The kind of service (web server, worker, database, cache, etc.) | | **Source** | Where the code comes from (Git repository, Docker image) | | **Dockerfile** | The Docker configuration for building and running the service | | **Environment variables** | Configuration values injected at runtime | | **Ports** | Network ports the service exposes | | **Health check** | Endpoint and settings for monitoring service health | | **Dependencies** | Other services this one depends on | ## Viewing services Services are displayed in the **right sidebar** of the chat interface under the **Services** tab.  ## Accepting and rejecting services After code analysis, detected services are in a **pending** state. You need to review and either **accept** or **reject** each one: - **Accept** — Include this service in the infrastructure plan and deployment - **Reject** — Exclude this service from deployment Only accepted services are included when generating infrastructure plans. ## Environment variables Each service can have its own set of environment variables. These are injected into the Docker container at runtime. ### Adding environment variables You can add environment variables in several ways: - **Automatically detected** — The AI extracts variables referenced in your code during analysis - **Through the chat** — Tell the AI: "Set DATABASE_URL to postgres://..." - **Through the sidebar** — Click on a service and add variables in the configuration panel ### Variable enrichment Hydron can automatically enrich environment variables by detecting common patterns: - Database connection strings - API keys and secrets - Port configurations - Service discovery URLs (connecting your services to each other) ### Shared secrets When multiple services need the same environment variable (e.g., a shared database URL), Hydron can automatically configure cross-service references so you only define the value once. ## Dockerfiles Every service needs a Dockerfile to define how it's built and run. Hydron handles this in three ways: 1. **Existing Dockerfile** — If your repository already has a Dockerfile, Hydron uses it 2. **AI-generated** — The AI creates an optimized Dockerfile based on the detected framework 3. **Custom** — You can provide or edit a Dockerfile through the chat ### Editing Dockerfiles Ask the AI to modify the Dockerfile for any service: - "Use a multi-stage build for the frontend service" - "Change the Node.js version to 20-alpine" - "Add a health check command to the API Dockerfile" ## Service dependencies Services can depend on other services. For example: ~~~ api-server ──depends on──> postgres api-server ──depends on──> redis frontend ──depends on──> api-server ~~~ Dependencies affect: - **Startup order** — Dependent services start after their dependencies - **Networking** — Dependent services can reach their dependencies via internal DNS - **Health checks** — A service isn't considered healthy until its dependencies are healthy ## Locking services You can **lock** a service to prevent accidental changes. A locked service: - Cannot have its Dockerfile modified - Cannot have environment variables changed - Cannot be removed from the project This is useful once you've finalized a service's configuration and don't want it accidentally modified during further iterations. --- # Environment Variables Environment variables are key-value pairs that configure your application at runtime. They're used for database connections, API keys, feature flags, and other settings that change between environments. ## How environment variables work in Hydron Environment variables in Hydron are: - **Encrypted at rest** — Sensitive values are encrypted with AES-256 - **Injected at runtime** — Passed to Docker containers when they start - **Per-service** — Each service has its own set of variables - **Never logged** — Sensitive values are redacted from deployment logs ## Setting environment variables ### During code analysis When Hydron analyzes your repository, it detects environment variables referenced in your code. Common patterns it recognizes: - `process.env.DATABASE_URL` (Node.js) - `os.environ.get('SECRET_KEY')` (Python) - `ENV['REDIS_URL']` (Ruby) - `.env` file references Detected variables appear in the service configuration with empty values for you to fill in. ### Through the chat Tell the AI to set environment variables: ``` "Set the DATABASE_URL for api-server to postgres://user:pass@host:5432/mydb" "Add a STRIPE_SECRET_KEY variable to the payment service" "Set NODE_ENV to production for all services" ``` ### Through the sidebar 1. Open the **Services** tab in the right sidebar 2. Click on a service 3. Find the **Environment Variables** section 4. Add, edit, or remove variables  ## Common environment variables Here are commonly used environment variables by category: ### Application | Variable | Description | Example | |----------|-------------|---------| | `NODE_ENV` | Runtime environment | `production` | | `PORT` | Server listen port | `3000` | | `HOST` | Server bind address | `0.0.0.0` | | `LOG_LEVEL` | Logging verbosity | `info` | ### Database | Variable | Description | Example | |----------|-------------|---------| | `DATABASE_URL` | Full connection string | `postgres://user:pass@host:5432/db` | | `DB_HOST` | Database hostname | `postgres.internal` | | `DB_PORT` | Database port | `5432` | | `DB_NAME` | Database name | `myapp` | | `DB_USER` | Database username | `app_user` | | `DB_PASSWORD` | Database password | `(secret)` | ### Cache & Queue | Variable | Description | Example | |----------|-------------|---------| | `REDIS_URL` | Redis connection string | `redis://redis:6379` | | `CACHE_TTL` | Cache time-to-live | `3600` | ### Authentication | Variable | Description | Example | |----------|-------------|---------| | `JWT_SECRET` | Token signing secret | `(secret)` | | `SESSION_SECRET` | Session encryption key | `(secret)` | | `OAUTH_CLIENT_ID` | OAuth client identifier | `abc123` | | `OAUTH_CLIENT_SECRET` | OAuth client secret | `(secret)` | ### External services | Variable | Description | Example | |----------|-------------|---------| | `STRIPE_SECRET_KEY` | Payment processing | `sk_live_...` | | `SMTP_HOST` | Email server | `smtp.gmail.com` | | `S3_BUCKET` | Storage bucket name | `my-app-uploads` | | `API_KEY` | Third-party API key | `(secret)` | ## Cross-service references When services within the same project need to communicate, Hydron can automatically configure cross-service environment variables. For example, if your `api-server` depends on a `postgres` service, Hydron sets: ~~~ api-server: DATABASE_URL = postgres://user:pass@postgres:5432/mydb ^^^^^^^^ Internal service name ~~~ Services within the same deployment can reach each other by their service name as the hostname. ## Best practices - **Never hardcode secrets** — Always use environment variables for API keys, passwords, and tokens - **Use descriptive names** — `DATABASE_URL` is better than `DB` - **Group related variables** — Use prefixes like `SMTP_`, `AWS_`, `STRIPE_` for organization - **Keep defaults sensible** — Set non-sensitive defaults where appropriate (ports, log levels) - **Document required variables** — Add descriptions to help team members understand what each variable does ## Updating variables after deployment To update environment variables after your app is deployed: 1. Change the values through the chat or sidebar 2. Ask the AI to redeploy the affected service 3. The container restarts with the new values Changes to environment variables require a container restart to take effect. --- # Domains & SSL Hydron automatically handles domain configuration and SSL certificate provisioning for your deployed applications. ## Default domains Every deployment on Hydron gets a default subdomain on `hydron.space`: ~~~ https://your-app-name.hydron.space ~~~ This domain is automatically configured with SSL and is immediately available after deployment. ## Custom domains You can connect your own domain to any deployed service. Hydron supports: - **Root domains** — `example.com` - **Subdomains** — `app.example.com`, `api.example.com` - **Wildcard subdomains** — `*.example.com` ### Setting up a custom domain 1. In the project chat, tell the AI: "Configure my domain example.com for this deployment" 2. The AI provides DNS records to add at your domain registrar 3. Add the DNS records (typically an A record or CNAME) 4. Once DNS propagates, Hydron automatically provisions an SSL certificate ### DNS record types | Record Type | When to use | |-------------|-------------| | **A record** | Point a root domain (`example.com`) to your server's IP | | **CNAME** | Point a subdomain (`app.example.com`) to your Hydron domain | ### DNS propagation DNS changes can take anywhere from a few minutes to 48 hours to propagate globally. In most cases, changes are visible within 5-30 minutes. Hydron will verify the DNS configuration and let you know when it's ready. ## SSL certificates Hydron automatically provisions and manages **free SSL certificates** for all your domains. This includes: - **Automatic issuance** — Certificates are provisioned once DNS is configured - **Auto-renewal** — Certificates are renewed before they expire - **HTTPS redirect** — HTTP traffic is automatically redirected to HTTPS - **Modern TLS** — TLS 1.2 and 1.3 with secure cipher suites You don't need to manage certificates manually — it's all handled automatically. ## Multiple domains You can point multiple domains to the same deployment: - `example.com` → your app - `www.example.com` → your app - `app.example.com` → your app Each domain gets its own SSL certificate. ## Domain management through OVH For domains registered through Hydron's OVH integration, you get additional DNS management capabilities directly within the platform. The AI can configure DNS records automatically without needing you to log into a separate domain registrar. ## Troubleshooting **SSL certificate not provisioning?** - Verify DNS records are correct: `dig example.com` should show your server's IP - Wait for DNS propagation (up to 48 hours in rare cases) - Ensure no CAA records block certificate issuance **Domain not resolving?** - Check that the A record points to the correct server IP - Verify there's no conflicting AAAA (IPv6) record - Clear your local DNS cache: `sudo dscacheutil -flushcache` (macOS) or `sudo systemd-resolve --flush-caches` (Linux) **Mixed content warnings?** - Ensure all resources in your app use HTTPS URLs - Update hardcoded HTTP URLs to use protocol-relative URLs or HTTPS --- # How It Works This page explains Hydron's full deployment pipeline — from the moment you connect your code to when your application is live and serving traffic. ## The deployment pipeline Hydron's deployment process consists of six stages: **Source Connection**, **Analysis**, **Planning**, **Provisioning**, **Building**, and **Deployment**. ## Stage 1: Source connection You provide the source of your application through one of three methods: - **Git repository** — GitHub, GitLab, Bitbucket, or any public URL - **Docker image** — An existing image from any Docker registry - **Template** — A pre-configured stack from the template gallery For Git repositories, Hydron clones the code to analyze it. For Docker images, analysis is skipped and you proceed directly to infrastructure planning.  ## Stage 2: Code analysis The AI performs a deep analysis of your codebase: **Language & framework detection** - Identifies programming languages and their versions - Detects frameworks (Express, Django, Rails, Spring, Next.js, etc.) - Reads package managers (npm, pip, bundler, maven, etc.) **Service discovery** - Finds entry points and service boundaries - Detects monorepo structures - Identifies background workers, API servers, and frontends **Configuration extraction** - Extracts environment variable references - Finds existing Dockerfiles - Detects port configurations and health check endpoints **Dependency mapping** - Maps service-to-service dependencies - Identifies database and cache requirements - Detects external service integrations The analysis results in a list of **services** with their configurations, which you review and approve.  ## Stage 3: Infrastructure planning Based on the analysis, the AI generates an **infrastructure plan** that specifies: ### Server selection The AI recommends server specifications based on your application's needs: ~~~ Application Analysis Recommended Server ───────────────────── ────────────────────── Node.js API + React KS-LE-B 3 services 4 vCPU, 16GB RAM Low-medium traffic 500GB SSD Frankfurt, DE ~~~ Factors considered: - Number and type of services - Expected resource usage (CPU, memory, disk) - Geographic location preference - Budget constraints ### Docker configuration For each service, a Dockerfile is either detected or generated. The AI creates optimized multi-stage builds that minimize image size and build time. ### Networking The plan defines: - Port mappings for each service - Internal networking between services - External port exposure for public-facing services - Reverse proxy configuration ### Environment & security - Environment variable definitions - SSL certificate requirements - Firewall rules - Security best practices You review the complete plan in the **Infrastructure** panel and can request changes through the chat before approving.  ## Stage 4: Server provisioning Once you approve the plan, Hydron provisions your dedicated server: ~~~ Provisioning Steps ┌─────────────────────────────────────────────────┐ │ [====] Install operating system Done │ │ [====] Configure networking Done │ │ [====] Install Docker & tools Done │ │ [====] Set up firewall rules Done │ │ [====] Configure SSH access Done │ │ [== ] Pull base images Running │ │ [ ] Configure reverse proxy Pending │ │ [ ] Set up SSL certificates Pending │ └─────────────────────────────────────────────────┘ ~~~ This includes: 1. **OS installation** — Ubuntu with the latest security patches 2. **Docker setup** — Docker Engine and Docker Compose 3. **Security hardening** — Firewall rules, SSH key configuration 4. **Networking** — Internal DNS, port forwarding 5. **Tooling** — Monitoring agents, log collection Each step is executed via SSH and you can watch the progress in real-time through the **Runs** panel. ## Stage 5: Build With the server ready, Hydron builds your application: 1. **Clone repository** (if Git source) or **pull image** (if Docker source) 2. **Build Docker images** using the configured Dockerfiles 3. **Push images** to the server 4. **Verify builds** — Ensure images are valid and contain expected artifacts Build logs are streamed in real-time so you can monitor progress and catch any issues. ## Stage 6: Deployment Finally, your application is deployed: 1. **Start containers** in the correct order based on dependencies 2. **Configure networking** between services 3. **Set up reverse proxy** (Nginx/Traefik) for routing 4. **Provision SSL** certificates 5. **Run health checks** to verify everything is working 6. **Configure domains** to point to the new deployment  ## After deployment Once your app is live, you can: - **Monitor** health status and resource usage - **View logs** in real-time from any service - **Redeploy** with code changes - **Scale** by upgrading server specifications - **SSH in** for direct server access ## Architecture overview Hydron consists of several internal services working together: - **Frontend** (React) — The user interface you interact with - **Backend** (Express) — API server managing business logic - **Code Analyzer** — Service that scans and analyzes repositories - **Code Deployer** — Service that builds Docker images and deploys them - **DevOps Runner** — Orchestration service for server provisioning - **LLM** (Claude) — AI engine making intelligent decisions at each stage The AI orchestrates the entire process, making intelligent decisions at each stage based on your code and requirements. --- # Code Analysis Code analysis is Hydron's process for understanding your application. The AI scans your repository to detect languages, frameworks, services, dependencies, and configuration requirements. ## What gets analyzed When you connect a Git repository, Hydron examines: | File type | What's extracted | |-----------|-----------------| | **Package files** (`package.json`, `requirements.txt`, `Gemfile`, etc.) | Dependencies, build scripts, entry points | | **Dockerfiles** | Existing container configurations | | **Config files** (`.env.example`, `config/`, etc.) | Environment variables, settings | | **Source code** | Framework detection, port usage, service boundaries | | **CI/CD files** (`.github/workflows/`, `Jenkinsfile`, etc.) | Build and deploy patterns | | **Documentation** (`README.md`, `docs/`) | Project description and setup instructions | ## Supported languages and frameworks Hydron supports a wide range of technologies: ### Backend | Language | Frameworks | |----------|-----------| | **Node.js** | Express, Fastify, NestJS, Koa, Hapi | | **Python** | Django, Flask, FastAPI, Celery | | **Ruby** | Rails, Sinatra | | **Java** | Spring Boot, Quarkus | | **Go** | Gin, Echo, Fiber | | **PHP** | Laravel, Symfony | | **Rust** | Actix, Axum, Rocket | | **.NET** | ASP.NET Core | ### Frontend | Framework | Description | |-----------|-------------| | **React** | Including Next.js, Gatsby, Remix | | **Vue.js** | Including Nuxt.js | | **Angular** | All major versions | | **Svelte** | Including SvelteKit | | **Static sites** | HTML/CSS/JS, Hugo, Jekyll, 11ty | ### Databases & services | Category | Technologies | |----------|-------------| | **SQL databases** | PostgreSQL, MySQL, MariaDB, SQLite | | **NoSQL databases** | MongoDB, Redis, Elasticsearch | | **Message queues** | RabbitMQ, Kafka, BullMQ | | **Search** | Elasticsearch, Meilisearch | ## The analysis process Code analysis happens in several steps: 1. **Clone Repository** — Download source code from Git 2. **File Discovery** — Scan directory structure, identify key files 3. **Language Detection** — Determine programming languages used 4. **Framework Detection** — Identify frameworks from dependencies and code patterns 5. **Service Discovery** — Find deployable components and their boundaries 6. **Configuration Extraction** — Extract environment variables and settings 7. **Dockerfile Analysis** — Check for existing Dockerfiles, assess quality 8. **Report Generation** — Compile findings into a structured analysis report  ## Analysis results After analysis completes, you'll see results in two places: ### In the chat The AI provides a summary of what it found: - Number of services detected - Key technologies identified - Required environment variables - Recommendations for Dockerfiles - Any issues or warnings ### In the sidebar The **Services** tab shows detailed results: - Each detected service with its configuration - Accept/reject controls for each service - Dockerfile preview and editing - Environment variable list ## Monorepo support Hydron handles monorepos by detecting multiple services within a single repository: Each service in a monorepo gets its own: - Dockerfile with correct build context - Environment variables - Port configuration - Health check settings ## Rerunning analysis You can rerun the code analysis at any time by asking the AI: - "Reanalyze the repository" - "Check for new services" - "Update the analysis with the latest code" This is useful after you've pushed changes to your repository or if you want the AI to focus on a specific directory. ## Limitations - **Binary files** are skipped (images, compiled assets, etc.) - **Very large repositories** (>1GB) may have longer analysis times - **Obfuscated or minified code** may not be fully analyzed - **Custom or niche frameworks** may require manual configuration hints If the AI misses something, you can always provide additional context through the chat. For example: "This project uses a custom Python framework based on Flask — treat it like a Flask app." --- # Infrastructure Plans An infrastructure plan is the AI-generated blueprint for deploying your application. It defines every aspect of the deployment — from server specifications to Docker configurations to networking. ## What's in a plan An infrastructure plan contains: ### Server configuration The plan specifies the dedicated server your application will run on: | Setting | Description | |---------|-------------| | **Server type** | Hardware specifications (CPU, RAM, storage) | | **Location** | Datacenter region for optimal latency | | **Operating system** | Typically Ubuntu 22.04 LTS | | **Commercial range** | Server tier (entry-level, business, enterprise) |  ### Service assignments Each service is assigned to a server with its configuration: - **Docker image** — Build configuration or registry reference - **Port mappings** — Container port to host port mappings - **Resource limits** — CPU and memory constraints - **Restart policy** — What happens when a container crashes - **Volumes** — Persistent data storage ### Networking - **Reverse proxy** — Nginx or Traefik configuration for routing - **Internal networking** — Service-to-service communication - **External access** — Which ports are publicly accessible - **Domain mapping** — Which domains point to which services ### Environment variables All environment variables for each service, including: - User-provided values - Auto-generated values (passwords, tokens) - Cross-service references (database URLs, service endpoints) ### Health checks Each service has a health check configuration: ## Viewing the plan The infrastructure plan is displayed in the **Infrastructure** tab on the right sidebar of the chat interface. It provides: - **Visual overview** of servers and service assignments - **Detailed configuration** for each component - **Server specifications** with hardware details - **Network topology** showing service relationships ## Modifying plans Plans are fully editable through the chat interface. Common modifications: ### Change server size "Use a server with 32GB RAM instead of 16GB" ### Change location "Move the server to the US East datacenter" ### Add a service "Add a Redis cache to the infrastructure plan" ### Change Docker configuration "Use Alpine-based images to reduce size" ### Modify networking "Expose the API on port 8080 instead of 3000" ### Adjust health checks "Change the health check interval to 60 seconds" After each modification, the AI updates the plan and shows you the changes. You can keep iterating until the plan matches your requirements. ## Plan states Plans go through several states: | State | Description | |-------|-------------| | **Draft** | Plan is being generated or modified | | **Ready** | Plan is complete and ready for review | | **Approved** | You've approved the plan for deployment | | **Executing** | Deployment is in progress | | **Completed** | Deployment finished successfully | | **Stale** | Services changed after plan was created | ### Stale plans A plan becomes **stale** if you modify services after the plan was generated. For example, if you add a new service or change environment variables, the existing plan may not account for these changes. When a plan is stale, Hydron notifies you and offers to regenerate it with the updated service configurations. ## Approving a plan When you're satisfied with the plan: 1. Review all sections in the Infrastructure panel 2. Verify server specs, services, and environment variables 3. Click **Approve** or tell the AI "Approve the plan" 4. The deployment process begins automatically Once approved, the plan is locked and deployment starts. You can still stop or pause the deployment if needed. ## Multiple servers For larger applications, a plan can include multiple servers. The AI determines the optimal distribution of services across servers based on resource requirements, security considerations, and performance.  ## Best practices - **Review carefully before approving** — The plan determines your entire infrastructure - **Ask questions** — If anything is unclear, ask the AI to explain specific choices - **Right-size servers** — Don't over-provision. You can always upgrade later - **Check environment variables** — Ensure all required values are set before deploying - **Consider location** — Choose a datacenter close to your users for lower latency --- # Server Provisioning Server provisioning is the process of setting up a dedicated server to run your application. Hydron automates the entire process — from OS installation to Docker setup to security hardening. ## What happens during provisioning When you approve an infrastructure plan, Hydron executes a series of provisioning steps on your dedicated server: 1. **OS Installation** — Install Ubuntu 22.04 LTS 2. **System Configuration** — Set hostname, configure timezone, update packages 3. **Security Setup** — Configure SSH keys, firewall (UFW), disable root password login, install fail2ban 4. **Docker Installation** — Install Docker Engine, Docker Compose, configure networking 5. **Application Setup** — Create directories, set up reverse proxy, configure SSL, log rotation 6. **Deployment** — Pull/build Docker images, start containers, verify health checks ## Provisioning plans Each server gets a detailed **provisioning plan** — a sequence of steps that transform a bare server into a ready-to-deploy environment. ### Step types | Type | Description | |------|-------------| | **Layout** | Server configuration and directory structure | | **Provisioning** | Software installation and system setup | | **Post-deployment** | Final configuration after containers are running | ### Step details Each step includes: - **Description** — What the step does - **Commands** — Shell commands to execute - **Expected output** — What successful completion looks like - **Rollback commands** — How to undo the step if it fails - **Environment variables** — Variables needed for the step ## Watching provisioning You can monitor the provisioning process in real-time through the **Runs** tab in the right sidebar:  Each step shows: - **Status** — Pending, running, completed, or failed - **Duration** — How long the step took or is taking - **Logs** — Click to expand and view real-time command output ## SSH access After provisioning completes, you have full SSH access to your server: ```bash ssh root@your-server-ip ``` Your SSH credentials are available in: - The deployment completion message in the chat - The **Server Inventory** page - The **Infrastructure** panel under server details ## Provisioning options ### Force OS install If your server already has an operating system, you can choose to: - **Keep existing OS** — Skip OS installation (faster, preserves data) - **Force reinstall** — Wipe and install a fresh OS (clean slate) ### Server location Hydron provisions servers in multiple datacenter locations. Choose a location close to your users for optimal latency: | Region | Locations | |--------|-----------| | **Europe** | Frankfurt, Paris, London, Amsterdam | | **North America** | New York, Montreal, San Francisco | | **Asia-Pacific** | Singapore, Sydney, Tokyo | ## Troubleshooting provisioning ### Step failed If a provisioning step fails: 1. Check the step's error logs in the Runs panel 2. The AI will suggest fixes based on the error 3. You can ask the AI to retry the failed step 4. Or SSH into the server to investigate manually ### Common issues **Network timeout during package installation** The server may have temporary network issues. Retry the step or ask the AI to retry. **Docker installation failure** Usually caused by OS compatibility issues. The AI will suggest alternative installation methods. **SSL certificate provisioning failure** DNS may not have propagated yet. Wait a few minutes and retry. ### Pausing and resuming You can **pause** a provisioning run at any time. This stops execution at the current step. When you **resume**, it picks up from where it left off. You can also **stop** a run entirely if you need to start over. This halts all execution but doesn't undo completed steps. --- # Server Inventory The Server Inventory is where you browse, manage, and monitor all your dedicated servers. It provides a comprehensive view of your infrastructure. ## Accessing the inventory Navigate to the **Inventory** page from the main sidebar. You'll see all your servers with their current status and details.  ## Server details Click on any server to open the details sidebar with comprehensive information:  ### Quick stats - Server name and status - Hardware specifications - Lifecycle and permission state ### Hardware specs - **CPU** — Core count, type, and frequency - **RAM** — Total memory capacity - **Storage** — Disk size and type (SSD/NVMe) ### Network information - **IP addresses** — Public IPv4 and IPv6 - **Bandwidth** — Speed and metering - **Internal IP** — Private network address (if applicable) ### Location - **Datacenter** — Physical location - **Zone** — Availability zone within the datacenter - **Region** — Geographic region ### System info - **Operating system** — Distribution and version - **Docker version** — Installed Docker Engine version - **Running services** — What's currently deployed ### Metadata - **Tags** — Custom labels for organization - **Notes** — Free-text notes about the server - **Linked project** — Which project uses this server ## Searching and filtering ### Search Type in the search bar to find servers by name, IP address, or tag. ### Filter by datacenter Use the datacenter filter to show servers in a specific location. ### Filter by commercial range Filter by server tier (entry-level, business, enterprise). ### Sort Sort servers by: - Name - Status - Location - Specifications ## Organizing servers ### Tags Add custom tags to organize your servers: - `production`, `staging`, `development` - `web`, `database`, `worker` - `client-name`, `project-name` - Any custom label that helps you organize Tags are searchable and make it easy to find groups of related servers. ### Notes Add notes to any server for documentation: - Setup instructions or special configurations - Contact information for the responsible team - Known issues or maintenance schedules - Anything you want to remember about the server ### Project linking Link servers to projects to track which servers belong to which deployment. A linked server appears in the project's Infrastructure panel and settings. ## Server states Servers go through several lifecycle states: | State | Description | |-------|-------------| | **Available** | Server is ready and not yet provisioned | | **Provisioning** | Server is being set up | | **Running** | Server is active with containers running | | **Stopped** | Server is powered off | | **Error** | Server has encountered an issue | ### Permission states | State | Description | |-------|-------------| | **Owned** | Full control over the server | | **Shared** | Limited access (team member) | | **Pending** | Awaiting access confirmation | ## Real-time updates The server inventory updates in real-time. You'll see: - **Provisioning progress** — Live progress bars during setup - **State changes** — Instant status updates - **New servers** — Automatically appear when provisioned No need to refresh the page — all updates stream live. ## Server actions From the inventory, you can: - **View details** — Open the server detail sidebar - **Add notes** — Document server configurations - **Add tags** — Organize with custom labels - **Link to project** — Associate with a deployment project - **Select for plan** — Use this server in an infrastructure plan ## Using inventory servers in plans When generating an infrastructure plan, you can choose to use servers from your inventory instead of provisioning new ones: 1. Generate an infrastructure plan 2. In the server selection step, click "Choose from inventory" 3. Select one or more servers from your inventory 4. The plan adapts to the selected server's specifications This is useful for: - Reusing existing servers for new deployments - Deploying to specific servers with particular hardware - Managing costs by consolidating services on fewer servers --- # Deployment Runs A deployment run tracks the execution of a deployment pipeline — from server provisioning through application startup. Every time you deploy or redeploy, a new run is created. ## Viewing runs Runs are displayed in the **Runs** tab on the right sidebar of the chat interface. Click on a run to view its detailed steps and logs.  ## Run steps Each run consists of multiple steps executed sequentially. ### Step statuses | Status | Indicator | Description | |--------|-----------|-------------| | **Pending** | Gray | Step hasn't started yet | | **Running** | Blue, animated | Step is currently executing | | **Completed** | Green | Step finished successfully | | **Failed** | Red | Step encountered an error | | **Skipped** | Gray, strikethrough | Step was skipped | ## Real-time logs Click on any step to view its real-time logs. Logs stream live during execution, showing the complete output of each command being executed on your server. ## Run controls ### Pause Pause an active run to temporarily halt execution. The current step finishes, then the run waits. Useful when you need to investigate something before proceeding. ### Resume Resume a paused run. Execution continues from where it was paused. ### Stop Stop a run entirely. This cancels any remaining steps. Completed steps are not rolled back. ## Run statuses | Status | Description | |--------|-------------| | **Started** | Run has been initiated | | **In Progress** | Steps are actively executing | | **Completed** | All steps finished successfully | | **Failed** | A step encountered an unrecoverable error | | **Paused** | Manually paused by user | | **Stopped** | Manually stopped by user | ## Failed runs When a run fails, the failed step is highlighted with error details and the AI will suggest fixes based on the error. You can: 1. Fix the issue (e.g., update the port configuration) 2. Ask the AI to modify the infrastructure plan 3. Redeploy, which creates a new run ## Redeployment To redeploy your application after code changes: 1. Push changes to your Git repository 2. In the project chat, ask: "Redeploy the application" 3. A new run is created with the latest code Redeployments are faster than initial deployments because: - The server is already provisioned - Docker layers are cached - Only changed components need rebuilding ## Run history All past runs are preserved in the Runs tab. You can: - Review what happened in previous deployments - Compare successful and failed runs - Track deployment frequency and duration - Debug recurring issues by examining historical logs Runs are ordered by most recent first, making it easy to find the latest deployment. --- # Account Setup This guide covers creating your Hydron account, signing in, and connecting external accounts. ## Creating an account To create a new Hydron account: 1. Go to the [registration page](https://hydron.space/register) 2. Enter your email address and a strong password 3. Complete the verification captcha 4. Click **Create Account** 5. Check your email for a verification link 6. Click the link to verify your email  Your account comes with **free credits** to try out the platform. ## Signing in ### Email and password 1. Go to the [login page](https://hydron.space/login) 2. Enter your email and password 3. If two-factor authentication is enabled, enter your 2FA code 4. Click **Sign In**  ### OAuth sign-in You can also sign in with your existing accounts: - **Google** — Sign in with your Google account - **GitHub** — Sign in with your GitHub account If you sign in with OAuth and an account with the same email already exists, you'll be prompted to link the accounts. ## Connecting OAuth accounts Link your Google or GitHub accounts to enable: - **Quick sign-in** — No need to remember a separate password - **Repository access** — Import private repositories (GitHub, GitLab, Bitbucket) - **Single sign-on** — Use the same identity across services ### To connect an OAuth account: 1. Go to **Settings** > **Connected Accounts** 2. Click **Connect** next to Google or GitHub 3. Authorize Hydron in the OAuth provider 4. Your account is now linked You can connect multiple providers to the same Hydron account. ### To disconnect an OAuth account: 1. Go to **Settings** > **Connected Accounts** 2. Click **Disconnect** next to the provider 3. Confirm the disconnection Make sure you have a password set before disconnecting all OAuth providers, or you won't be able to sign in. ## Email verification Email verification is required to access all features. If you haven't verified your email: 1. Check your inbox for the verification email 2. Click the verification link 3. If you don't see it, check your spam folder 4. Request a new verification email from the login page ## Password reset If you've forgotten your password: 1. Go to the [forgot password page](https://hydron.space/forgot-password) 2. Enter your email address 3. Check your email for a reset link 4. Click the link and enter a new password Password reset links expire after a set time period for security. ## Profile settings Manage your profile from **Settings** > **Profile**:  - **Name** — Your display name - **Email** — Your account email (requires reverification if changed) - **Avatar** — Upload a profile picture or use a monogram - **Password** — Change your password ### Avatar customization You can set your profile picture in two ways: 1. **Upload an image** — Upload a photo and crop it to fit 2. **Monogram** — Use your initials with a custom color ## Account deletion To permanently delete your account: 1. Go to **Settings** > **Danger Zone** 2. Click **Delete Account** 3. Confirm by typing your email address 4. Click **Confirm Delete** Account deletion is permanent. All your projects, chats, and deployment history will be removed. Active servers are **not** automatically terminated — make sure to handle your infrastructure before deleting your account. --- # Security Hydron takes security seriously at every level — from account protection to data encryption to server hardening. This page covers the security features available to you and best practices. ## Two-factor authentication (2FA) Two-factor authentication adds an extra layer of security to your account. Even if someone knows your password, they can't sign in without your 2FA code. ### Enabling 2FA 1. Go to **Settings** > **Security** 2. Click **Enable Two-Factor Authentication** 3. Scan the QR code with your authenticator app (Google Authenticator, Authy, 1Password, etc.) 4. Enter the 6-digit code from your authenticator to confirm 5. Save your **backup codes** in a secure location ### Using 2FA After enabling 2FA, you'll be asked for a 6-digit code each time you sign in: 1. Enter your email and password 2. Open your authenticator app 3. Enter the current 6-digit code 4. Click **Verify** ### Backup codes When you enable 2FA, you receive one-time backup codes. These can be used if you lose access to your authenticator app: - Each code can only be used once - Store them in a secure location (password manager, printed copy in a safe) - Generate new backup codes from Settings if you run out ### Disabling 2FA 1. Go to **Settings** > **Security** 2. Click **Disable Two-Factor Authentication** 3. Enter your current 2FA code to confirm 4. 2FA is now disabled ## Session management ### Active sessions View all your active sessions from **Settings** > **Sessions**:  - See which devices and browsers are signed in - View IP addresses and locations - See when each session was last active - **Sign out** individual sessions or all sessions at once ### Session security Hydron protects your sessions with: - **Token rotation** — Refresh tokens are rotated on each use - **IP validation** — Sessions are tied to IP addresses (optional) - **User agent validation** — Sessions are tied to browser fingerprints (optional) - **Automatic expiry** — Inactive sessions expire after a set period ## Data encryption ### At rest - **Credentials** — Server SSH keys and API credentials are encrypted with AES-256 - **Environment variables** — Sensitive values are encrypted before storage - **Passwords** — Hashed with bcrypt/argon2 (never stored in plaintext) ### In transit - **HTTPS everywhere** — All connections use TLS 1.2 or 1.3 - **SSH** — Server communication uses SSH with key-based authentication - **API calls** — All API traffic is encrypted ## Server security When Hydron provisions a server, it automatically applies security best practices: | Security measure | Description | |-----------------|-------------| | **Firewall** | UFW configured to allow only necessary ports | | **SSH hardening** | Key-based auth only, root password login disabled | | **Fail2ban** | Automatic IP blocking after failed login attempts | | **OS updates** | Latest security patches applied during provisioning | | **Docker isolation** | Applications run in isolated containers | | **HTTPS** | Automatic SSL certificate provisioning | ## Best practices ### Account security - **Use a strong, unique password** — At least 12 characters with mixed case, numbers, and symbols - **Enable 2FA** — Adds significant protection against unauthorized access - **Use OAuth** — Sign in with Google or GitHub for additional security - **Review sessions regularly** — Sign out of devices you don't recognize - **Don't share credentials** — Each team member should have their own account ### Application security - **Use environment variables** — Never hardcode secrets in your code - **Rotate secrets periodically** — Change API keys and passwords regularly - **Limit SSH access** — Only allow SSH from known IP addresses - **Keep dependencies updated** — Regularly update your application dependencies - **Monitor logs** — Check deployment and server logs for suspicious activity ### Infrastructure security - **Don't expose unnecessary ports** — Only expose ports that need public access - **Use internal networking** — Services should communicate via internal networks, not public IPs - **Back up your data** — Regularly back up databases and important data - **Monitor server resources** — Unusual CPU or network usage may indicate a security issue --- # Billing & Credits Hydron uses a credit-based billing system. Credits are consumed when you use AI features and deploy infrastructure. This page explains how billing works. ## How credits work Credits are the currency for using Hydron's services. They're consumed by: | Action | Credit cost | |--------|------------| | **AI chat messages** | Based on message length and AI model | | **Code analysis** | Based on repository size | | **Infrastructure planning** | Based on plan complexity | | **Server provisioning** | Based on server tier and duration | Credits are deducted as you use features. You can track your balance and usage in real-time. ## Free tier Every new account receives **free credits** to explore the platform. The free tier lets you: - Chat with the AI assistant - Analyze code repositories - Generate infrastructure plans - Experience the full deployment flow No credit card required to get started. ## Checking your balance View your current credit balance and usage from **Settings** > **Usage**. The usage dashboard shows a breakdown of credit consumption across AI conversations, code analysis, infrastructure planning, and server provisioning. ## Purchasing credits To add more credits to your account: 1. Go to **Settings** > **Billing** 2. Click **Purchase Credits** 3. Select a credit package 4. Complete payment via Stripe Hydron accepts all major credit and debit cards through Stripe's secure payment processing. ## Auto-topup Enable auto-topup to automatically purchase credits when your balance runs low: 1. Go to **Settings** > **Billing** 2. Enable **Auto-topup** 3. Set your threshold (e.g., "topup when balance falls below 100 credits") 4. Set the topup amount (e.g., "add 1,000 credits") Auto-topup ensures your deployments are never interrupted by insufficient credits. ## Subscriptions For regular usage, credit subscriptions offer better value: - **Monthly credit packages** at discounted rates - **Automatic renewal** so you never run out - **Cancel anytime** — unused credits carry over Manage subscriptions from **Settings** > **Billing**. ## Usage tracking Detailed usage tracking helps you understand your spending: ### Per-project usage See how many credits each project consumes, helping you identify cost drivers. ### Server usage Track credit consumption per server, including provisioning and runtime costs. ### Historical usage View usage trends over time to predict future needs and budget accordingly. ## Payment methods Manage your payment methods from **Settings** > **Billing**: - Add credit or debit cards - Set a default payment method - Remove old payment methods - View payment history All payments are processed securely through Stripe. Hydron never stores your full card details. ## Billing history View your complete billing history: - **Credit purchases** — When and how many credits you bought - **Credit usage** — Detailed breakdown of credit consumption - **Invoices** — Download invoices for accounting ## Cost optimization tips - **Right-size servers** — Don't provision more resources than you need - **Use templates** — Pre-configured templates optimize resource usage - **Monitor usage** — Check the usage dashboard regularly - **Clean up unused projects** — Remove projects you no longer need - **Use auto-topup** — Avoid service interruptions from insufficient credits --- # Hydron Public Roadmap The canonical roadmap is also available as a standalone markdown file at `/roadmap.md`. > What Hydron is building over the next three months, organized as Now / Next / Later. No fake deadlines — the order reflects what unblocks the most users, in the rough sequence it will land. Quick links: - Rendered roadmap page: https://hydron.app/roadmap - llms.txt directive: https://hydron.app/llms.txt - Documentation: https://hydron.app/docs - Blog: https://hydron.app/blog ## Now _Actively underway, shipping in the early weeks of the period._ ### Zero-downtime rolling deploys - **Theme**: Reliability - **Anchor**: https://hydron.app/roadmap#zero-downtime-deploys Every Hydron deploy will swap containers in place — the new version goes live and proves itself healthy before the old one shuts down. No more 502s during release windows, no more reload-and-pray. **Why we're building it:** If your users see a 502 every time you ship, you aren't really shipping continuously. Zero-downtime is table stakes for production. **Best for:** Customer-facing applications, High-traffic APIs, Teams that deploy multiple times a day. ## Next _Starts once the Now items land — expected mid-period._ ### Team accounts with shared billing & roles - **Theme**: Teams & collaboration - **Anchor**: https://hydron.app/roadmap#team-accounts Multiple developers, one billing account, the right permissions per person. Invite your team, set roles, and stop juggling shared logins. **Why we're building it:** Hydron stops being a tool and starts being a platform the moment a teammate wants in. Teams should never have to share passwords, and your bill shouldn't depend on which person clicked Deploy. **Best for:** Teams of 3–15 developers, Agencies managing client deployments, Anyone who wants a deploy log instead of a Slack thread. ### MCP server — deeper agent control over Hydron - **Theme**: AI agent surface - **Anchor**: https://hydron.app/roadmap#mcp-server Expand the Model Context Protocol server so any AI coding agent — Claude Code, Cursor, Codex, anything that speaks MCP — can drive a complete Hydron deployment end-to-end without ever leaving the editor. **Why we're building it:** If an AI agent is doing the building, it should also be able to do the shipping. Hydron's MCP server is the bridge — making sure no operation requires breaking out of the AI workflow you're already in. **Best for:** Claude Code, Cursor, Codex & Aider users, Teams running agentic dev loops, Anyone building on top of the Hydron API. ## Later _Larger investments lined up for the back end of the period._ ### Vercel / Heroku / Render migration assistant - **Theme**: Migration & onboarding - **Anchor**: https://hydron.app/roadmap#migration-assistant Point Hydron at your current host. We'll read your build settings, environment variables, and add-ons (Postgres, Redis, ...), generate the matching Hydron configuration, and walk you through database transfer and DNS cutover. **Why we're building it:** Migrating off a managed platform usually takes days of manual config rebuilding. Most of that work is mechanical — exactly the kind of thing AI should do for you. **Best for:** Vercel, Heroku, Render, and Railway customers, Teams whose bill outgrew the convenience, Anyone who wants out without a re-platforming project. ## How we plan - **Production trust before new surface area** — reliability work comes ahead of net-new product. - **Honest pricing, in public** — if you can't price Hydron without talking to us, that's a bug. - **Teams & agencies are first-class users** — multi-user accounts are a default, not an enterprise tier. - **Migration is the unlock** — the cost of getting in should never outweigh the cost of staying put. ## Requesting a feature Feature requests go through the contact form at https://hydron.app/contact. Specific, concrete asks tied to a real workflow carry the most weight. --- # Hydron Blog Posts Below are all published blog posts. Each is also available as a standalone markdown file at `/blog/{slug}.md`. ## From repo URL to production: a tour of Hydron's deployment pipeline _2026-05-26 · Engineering · by The Hydron Team · 12 min read_ > 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. ---