# Self-Hosting SecondStack > How SecondStack is self-hosted: deploy it with Docker Compose on your own Linux VM, connect your LLM providers, and manage your users, teams, and budgets. Canonical: Updated: 2026-07-07 --- SecondStack is designed to run on **your own infrastructure**. It is not a SaaS product: you deploy it on a virtual machine you control, connect your own LLM providers, and keep all data in your environment. ## Deployment model The platform ships as a set of containerized services orchestrated with **Docker Compose**, using pre-built images. The simplest deployment is a single Linux VM: unpack the release, set a few environment variables, and run the initialization script. For production, you expose the VM over HTTPS, point a DNS domain at it, and connect enterprise single sign-on. If you would rather not operate it yourself, SecondStack can also **host and manage a single-tenant, dedicated deployment** for you — the platform stays isolated to your organization rather than shared multi-tenant SaaS. ## Three steps to production 1. **Deploy.** Provision a Linux VM and run the platform setup. Docker Compose brings up every service — PostgreSQL, OpenResty, the LLM gateway, Authentik, content extraction, search, and the dashboards — pre-configured. 2. **Connect providers.** Add your LLM provider API keys in [ControlTower](/features/controltower/). Supported providers include Anthropic, OpenAI, Azure, Google AI Studio, OpenRouter, and Databricks, plus self-hosted inference endpoints. Group models by capability and set access and pricing. 3. **Manage users and teams.** Create teams, assign [budgets](/features/cost-management/), and synchronize with your identity provider groups. Control spend and model access at the team level. ## Minimum requirements | Requirement | Detail | |---|---| | Compute | A Linux VM with **4 vCPU, 16 GB RAM, and ~200 GB SSD** (container images alone need ~50 GB). | | Networking | A **DNS name** with subdomains for the chat, admin, and gateway services, pointing at the VM. | | Inbound ports | **443** (HTTPS) and **22** (SSH); port **80** only for certificate challenges. | | Identity | An **OAuth client** in your identity provider — Entra ID (Azure AD), Okta, or Keycloak — for single sign-on. | | Object storage | An **S3-compatible bucket** (bring your own — e.g. AWS S3, Cloudflare R2, MinIO, or Tigris) for agent sandboxes and file transfer. | | LLM access | At least one **upstream LLM provider** API key or endpoint. | :::note An S3-compatible bucket is a required dependency — the platform does not ship its own object store. It is used for transient file transfer between SecondChat and agent sandboxes. ::: ## Authentication SecondStack authenticates users over OAuth. It includes a built-in **Authentik** identity core, so it can run standalone, but enterprise deployments normally federate to an upstream identity provider such as Entra ID (Azure AD), Okta, or Keycloak. Group membership synced from your IdP drives team assignment and model access. ## Operations - **Backups** — automated PostgreSQL backups run on a schedule, with daily and weekly retention. - **Monitoring** — disk and container health checks help you keep the deployment stable. - **Configuration** — provider, model, prompt, guardrail, and team configuration is managed in ControlTower and applied to the running services. ## Supported components and support model The platform packages a number of open-source components — including **Authentik, PostgreSQL, Meilisearch, Qdrant, Kreuzberg, and OpenResty** — alongside SecondStack's own services. As the platform vendor, SecondStack supports the whole stack end to end, so you have a single point of contact rather than separate vendor relationships for each component. ## Next steps - See how traffic flows through the gateway in [API Routing](/features/api-routing/). - Configure models, providers, and policy in [ControlTower](/features/controltower/). - Review common deployment questions in the [FAQ](/resources/faq/).