<!-- llms-txt: https://hydron.app/llms.txt -->
<!-- llms-full-txt: https://hydron.app/llms-full.txt -->
<!-- canonical: https://hydron.app/docs/concepts -->

# 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.

![The Hydron interface showing projects, chats, and services working together](/images/docs/chat-calcom.png)

## 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**

![The Projects dashboard with project cards organized in a grid](/images/docs/projects-dashboard.png)

**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

![The Server Inventory showing dedicated servers with their specifications](/images/docs/server-inventory.png)

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
