Home

Hostess — Docker Compose for Production

The deployment platform that just works.

The Problem

Modern deployment tooling is broken. Developers are stuck choosing between three bad options:

1. Big Cloud (AWS, Azure, GCP)

2. Managed Platforms (Vercel, Supabase, Render)

3. DIY Platforms (Railway, Render, Fly)

The result? Developers waste weeks wrestling with infrastructure instead of shipping features.

The Solution

Hostess is Docker Compose for production—almost literally.

One hostess.yml file. One hostess deploy command. Instant deployment to the web.

version: "1.0"
name: my-app

services:
  web:
    type: nextjs
    build:
      source: ./frontend
    env:
      NEXT_PUBLIC_API_URL: ${api.external_url}

  api:
    type: fastapi
    build:
      source: ./backend
    env:
      DATABASE_URL: ${db.url}
      REDIS_URL: ${cache.url}

  db:
    type: postgres
    resources: large

  cache:
    type: redis

$ hostess deploy
✓ Building web...
✓ Building api...
✓ Provisioning db...
✓ Provisioning cache...
✓ Deploying services...

🚀 Deployment complete!

  web:   https://my-app-web-k7xm9p2q.hostess.run
  api:   https://my-app-api-a3x9d2m1.hostess.run
  db:    postgresql://user:password@my-app-db-m2x8k9n4.hostess.run:5432/db
  cache: redis://password@my-app-cache-p1v7j3l5.hostess.run:6379

What Makes Hostess Different

1. Single Source of Truth

hostess.yml is to production deployments what docker-compose.yml is to local dev. Your entire stack—frontend, backend, databases, workers—lives in one declarative config file checked into version control.

2. GitOps by Default

3. Zero Configuration Overhead

4. Framework-Optimized Dashboards

Unlike generic platforms, Hostess provides custom dashboards for specific frameworks:

Real-time insights without configuring observability tools.

5. Magic Variables (Service Discovery That Works)

Reference services by name, get fully-qualified URLs automatically:

api:
  env:
    DATABASE_URL: ${db.url}           # Internal cluster URL
    REDIS_URL: ${cache.url}

frontend:
  env:
    NEXT_PUBLIC_API_URL: ${api.external_url}  # Public internet URL

Hostess generates both internal URLs (for service-to-service communication) and external URLs (for browsers and developers), all with automatic HTTPS.

6. OSS-Friendly: Make Any App Deployable by Anyone

hostess.yml makes your application redistributable. Want to self-host Supabase, Infisical, or Cal.com without Terraform/K8s knowledge?

$ git clone https://github.com/supabase/supabase
$ cd supabase
$ cat hostess.yml  # Already there
$ hostess deploy   # That's it

Build any open-source platform and let anyone deploy it for themselves in one command. No cloud expertise required.

7. Cost Transparency

Core Features

Multi-Service Orchestration

Deploy entire stacks as one atomic unit. Services wait for dependencies to be healthy before starting.

Operator-Backed Databases

Postgres and Redis provisioned via Kubernetes operators (CloudNativePG, Redis FailoverSet). Production-ready HA, backups, and failover—no configuration required.

Lifecycle Hooks

Run migrations, seed databases, warm caches—all declaratively:

api:
  lifecycle:
    migrate:
      command: ["alembic", "upgrade", "head"]
      on_failure: abort
    post_deploy:
      command: ["python", "scripts/warmup_cache.py"]

Autoscaling

CPU-based horizontal pod autoscaling out of the box:

api:
  replicas:
    min: 2
    max: 10
    target_cpu: 70

Real-Time Observability

Secrets Management

Integrated with Infisical for secure secret storage:

$ hostess secrets set JWT_SECRET
$ hostess secrets set STRIPE_KEY --value sk_live_abc123

Reference secrets in your config:

env:
  JWT_SECRET: ${secret:JWT_SECRET}
  STRIPE_KEY: ${secret:STRIPE_KEY}

Preview Environments

Automatic ephemeral environments for every pull request:

environments:
  production:
    branch: main

  preview:
    branches: ["*"]
    ephemeral: true
    ttl: 7d

Each PR gets isolated services with unique URLs. Cleanup happens automatically when the PR closes.

Custom Domains

Bring your own domain with automatic SSL:

frontend:
  domains:
    - myapp.com
    - www.myapp.com

api:
  domains:
    - api.myapp.com

Hostess handles Let's Encrypt certificates and DNS validation.

Supported Service Types

Hostess provides first-class support with optimized defaults and custom dashboards:

Web Frameworks

Databases

Generic

Coming soon: MongoDB, MinIO, RabbitMQ, vLLM (GPU inference)

The Platform Vision

Phase 1: Multi-Service Deployments (v1.0) — Q1 2026

Core platform for teams deploying their own apps. One-command deploys, GitOps, preview environments, observability.

Phase 2: Platforms SDK (v1.3–v1.4) — Q2 2026

Turn any deployable app into a sellable platform. Developers can:

Example: Build a CRM, publish a template, let customers deploy their own isolated instance—like Retool or Metabase, but for any app.

Phase 3: Multi-Cloud Support (v1.3–v1.4) — Q3 2026

Expand beyond GKE to EKS (AWS) and AKS (Azure). Cloud provider is just a config change:

cloud:
  provider: aws
  region: us-east-1

Same hostess.yml, different backend execution.

Phase 4: Enterprise BYOC (v1.4+) — Q4 2026

Connect any Kubernetes cluster regardless of provider. Custom/Enterprise tier for teams with existing infrastructure.

Market Positioning

PlatformBest ForWeakness
AWS/GCP/AzureEnterprise with dedicated DevOpsToo complex for small teams
VercelSingle Next.js appsNo multi-service support
SupabaseManaged Postgres + AuthNot for custom stacks
RailwaySimple deploymentsLimited GitOps primitives
RenderBasic multi-serviceNo service discovery
Fly.ioEdge deploymentsSteep learning curve
HostessMulti-service full-stack appsNew platform (limited track record)

Hostess occupies the gap: Too complex for Vercel, too simple for AWS, more GitOps than Railway, more flexible than Render.

Use Cases

1. SaaS Startups

Deploy your entire stack—frontend, API, database, worker, cache—with one command. Focus on product, not infrastructure.

2. Open-Source Platforms

Distribute your project as a hostess.yml file. Anyone can deploy it without Terraform knowledge. Examples:

3. Development Teams

4. AI Coding Agents

The deployment target for autonomous development. Agent frameworks can integrate Hostess as their deploy backend — the developer provides a PAT, the agent handles the rest. No computer use, no GUI, no friction. The entire write-deploy-debug-redeploy loop stays in the terminal where agents are fastest.

5. Platform Builders (v1.3+)

Turn your app into a multi-tenant SaaS. Provision isolated customer environments with the Platforms SDK.

Business Model

Pricing Strategy (Draft)

Open Questions:

Strategy: Get the platform into the hands of dev teams first, gather feedback, iterate on pricing based on real usage patterns.

Current Status

What's Built (v1.0 Core)

What's Next (Pre-Launch)

Timeline: Launch-ready by Q1 2026.

Why I'm Building This

I'm a developer who's built many kinds of software—AI engineering, SWE, full-stack apps. I know the pain of managing cloud infrastructure firsthand:

Cloud providers are greedy. Managed platforms are fragmented. DIY platforms are incomplete.

Hostess is the tool I wish existed when I started building software.

Developer Experience Example

Before Hostess

# Set up infrastructure
$ terraform init
$ terraform apply  # 15 minutes, 200+ lines of config

# Configure databases
$ kubectl apply -f postgres-operator.yaml
$ kubectl apply -f redis-operator.yaml
$ kubectl apply -f postgres-cluster.yaml
$ kubectl apply -f redis-cluster.yaml

# Deploy services
$ docker build -t myapp/frontend .
$ docker push myapp/frontend
$ kubectl apply -f frontend-deployment.yaml
$ kubectl apply -f frontend-service.yaml
$ kubectl apply -f frontend-ingress.yaml

# Repeat for backend...
# Set up secrets manually...
# Configure DNS records...
# Debug why services can't talk to each other...

Total time: 4-8 hours (if you know what you're doing)

With Hostess

$ hostess deploy

Total time: 3 minutes

Competitive Advantages

  1. GitOps-first: Version control is the source of truth, not a dashboard
  2. Framework awareness: Custom dashboards for Next.js, FastAPI, Postgres, Redis
  3. OSS redistribution: Make any app deployable-by-anyone with one config file
  4. Multi-service native: Built for full-stack apps, not retrofitted from single-app platforms
  5. Kubernetes under the hood: Production-grade orchestration without the YAML hell
  6. Magic variables: Service discovery that actually works without manual DNS setup
  7. Platforms SDK roadmap: Path to enabling multi-tenant SaaS builders
  8. AI-agent native: The entire deploy-debug-redeploy loop is CLI-driven — purpose-built for autonomous coding agents

The AI Agent Advantage

Hostess is the deployment platform AI coding agents would choose for themselves.

The rise of autonomous coding agents (Claude Code, Devin, Cursor, Copilot Workspace, OpenAI Codex) is creating a new class of "developer" that writes, deploys, and iterates on code without human intervention. These agents have a fundamental constraint: they work best in text-in, text-out environments. Every time an agent has to navigate a GUI — click through a cloud console, switch between dashboard tabs, interact with a visual CI/CD pipeline — it becomes slower, more brittle, and more error-prone.

Hostess's entire workflow is CLI and config-file driven. After a one-time account setup and PAT (Personal Access Token) generation, an AI agent never needs to touch a GUI again:

# Authenticate (once, via environment variable)
export HOSTESS_TOKEN=pat_xxxxxxxx

# The entire agent loop — pure stdin/stdout
hostess deploy                          # Deploy the full stack
hostess services logs api               # Check for errors
hostess secrets set OPENAI_KEY --value sk-...  # Manage secrets
hostess deployments list                # Inspect state
hostess deploy                          # Redeploy after code changes

No browser automation. No computer-use overhead. No fragile UI navigation. Just text commands and a declarative config file — both of which are native operations for any LLM.

Why This Matters Now

Every AI-powered application is inherently a multi-service stack: a frontend, an API layer, a database, a vector store, a model-serving endpoint, a worker queue for async inference. This is exactly the architecture Hostess is built to deploy. As AI coding agents become the primary way software gets built, the platform that agents deploy to most easily will win by default.

Comparison: Agent Deploying to AWS vs. Hostess

OperationAWS (Agent Experience)Hostess (Agent Experience)
Define infrastructureWrite Terraform HCL or navigate console (computer use)Write hostess.yml (plain text)
Set secretsAWS Secrets Manager CLI + IAM permissionshostess secrets set KEY
DeployMulti-step CI/CD pipeline with console verificationhostess deploy
Check statusParse CloudWatch dashboards (computer use)hostess deployments list
Read logsCloudWatch Logs CLI with complex filter syntaxhostess services logs api
Debug databaseOpen pgAdmin or RDS console (computer use)hostess connect db
Full iteration cycle15+ commands across multiple toolsEdit code → hostess deploy

An AI coding agent can go from writing code to deploying it to reading logs to fixing a bug to redeploying — in a single agentic loop, never leaving the terminal. That's an order of magnitude faster than any alternative.

The Implication

Agent frameworks and AI IDEs will need a default deployment target. The platform with the lowest friction — fewest commands, no GUI dependencies, declarative config that an LLM can author natively — becomes that default. Hostess is that platform.

Risks & Mitigations

Risk: "Another deployment platform?"

Mitigation: Hostess targets the gap between simple platforms (Vercel) and complex cloud (AWS). Multi-service GitOps is underserved.

Risk: Kubernetes complexity leaks through

Mitigation: Ruthless abstraction. Users never write YAML, never run kubectl. Platform handles operators, networking, DNS.

Risk: Cost of hosting (Postgres, Redis, compute)

Mitigation: Start with GKE Autopilot (pay only for what you use). Scale to multi-cloud (AWS, Azure) to optimize costs. BYOC for Enterprise.

Risk: Limited adoption without proven track record

Mitigation: Focus on OSS redistribution. Get Hostess adopted as the "official" deployment method for popular OSS projects (Supabase, Infisical, etc.).

What Comes After Launch

Post-v1.0 Roadmap

Summary

Hostess is Docker Compose for production.

One config file. One command. Entire stack deployed.

The mission: Make deploying full-stack apps as easy as running docker compose up.

Status: Core platform complete, finalizing for Q1 2026 launch.

Contact: Immanuel Peter | GitHub | immanuel.peter1@gmail.com