Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS

Register Here!

A self-hosted internal developer platform that stays inside your security boundary

Massdriver Self-Hosted installs with a Helm chart on your own Kubernetes cluster. Infrastructure state, secrets, deployment history, and audit records stay in your environment, and it runs in air-gapped networks with no dependency on an outside service.

Developers get governed self-service from an approved catalog, with policy before every apply, attribute-based access, and an audit trail your security team owns.

Get My Platform BuiltHow Massdriver handles security
Massdriver installs with Helm on your own Kubernetes cluster inside your security boundary. The UI and API, Argo Workflows, IaC state, secrets, deploy history, and audit log all run there and deploy to your AWS, Azure, and GCP accounts. Outside services are not required, so it runs air-gapped.

The vendor review said no. The platform still has to exist.

Teams usually search for a self-hosted internal developer platform after a security review. The product looked right, and then someone asked where the cloud credentials, the state files, the network topology, and the deployment history would live. For a SaaS platform the answer is somewhere outside your network, and for many regulated teams that ends the evaluation.

The requirement is often stated as “it has to run on our infrastructure,” but the details matter. Some teams only need cloud credentials to stay inside, so a self-hosted runner for a SaaS control plane is enough. Others need the whole control plane inside the boundary: the catalog, the policy decisions, the approval records, and the audit trail, because the system that decides who may change production is part of what the assessor reviews.

When nothing on the market fits, the fallback is a homegrown build. For a team of three, a first production version of the ten systems behind a platform takes about 18 months and $900,000 in salary, before maintenance. Choosing a self-hosted platform is mostly a decision about which of those systems you want to run as software you install, and which you want to write.

The options for a platform that cannot leave your network

Each one can satisfy a self-hosting requirement. They differ in what stays inside and how much you build.

  • Build the platform in-house

    What you get

    Exactly the platform you design, inside your boundary from day one.

    What you still build or accept

    All ten systems, from the catalog and form generation to policy, state, RBAC, audit, and the portal, plus a product team to keep them running.

  • Self-hosted Backstage plus your own automation

    What you get

    A mature open source portal inside your network, with a software catalog and templates.

    What you still build or accept

    Everything behind the portal: the pipelines, credentials, state, policy checks, approvals, and the change record.

  • Terraform Enterprise

    What you get

    Self-hosted Terraform runs, state, a private module registry, and policy as code with Sentinel or OPA.

    What you still build or accept

    The developer-facing platform above Terraform: how modules compose into environments, and the same model for Helm and for callers such as agents.

  • SaaS control plane with self-hosted runners

    What you get

    Plans and applies run on workers in your network, so cloud credentials stay inside.

    What you still build or accept

    Topology, metadata, policy decisions, and audit records in the vendor’s cloud. That works for some reviews and fails others.

  • Massdriver Self-Hosted

    What you get

    The full platform installed from a Helm chart on your cluster: catalog, generated pipelines, policy, attribute-based access, approvals, the environment graph, and the audit log.

    What you still build or accept

    Running the install like any other service in your cluster, including upgrades on your schedule.

What runs in your environment

The Helm chart installs the full Massdriver platform. You bring the cluster, a database, mail, and a domain.

Massdriver and its UI

The platform and the UI install into a namespace on Kubernetes 1.25 or later. Chart upgrades bring new platform and UI images.

Argo Workflows for every deploy

Plans and applies run as workflows inside your cluster, on your network, with credentials that never leave it.

Object storage through MinIO

The chart includes S3-compatible object storage through MinIO, so the install has no outside storage dependency.

Your PostgreSQL, mail, and domain

You provide PostgreSQL 13.25 or later with the citext, uuid-ossp, and pg_stat_statements extensions, an SMTP server for account email and alerts, and the domain the instance runs on.

Your identity provider

Sign-in goes through your identity provider over OIDC or SAML 2.0, such as Okta or Azure Entra ID, and access follows attribute-based policies by team and environment.

Your observability stack

OpenTelemetry tracing exports to your collector, and audit records can go to your SIEM, so platform activity shows up where your operations team already looks.

One production change, entirely inside your boundary

An engineer needs to raise the storage on a production database. Every step below runs on infrastructure you operate.

  1. 1

    Sign-in through your identity provider

    The engineer signs in with your SSO. Their groups come from your identity provider, so access follows the teams you already manage there.

  2. 2

    The change starts from the approved catalog

    The database was deployed from a bundle in your private catalog. The engineer changes the storage field, and the bundle’s schema accepts only the sizes your platform team allows.

  3. 3

    Policy runs inside the cluster

    Attribute-based policy decides that this engineer may propose a production change and may not deploy it alone. Policy checks (SOC 2, HIPAA, CIS) run against the plan inside your cluster.

  4. 4

    A second person approves

    Separation of duty is on for production, so a lead who did not propose the change reviews the diff and the policy results and approves it.

  5. 5

    The apply runs as a workflow in your cluster

    An Argo workflow plans and applies on your network, with cloud credentials that never leave it. State and deployment history stay in your environment.

  6. 6

    The record goes where your auditors look

    The change carries the proposer, the approver, the diff, the policy results, and the outcome. Audit records can go to your SIEM alongside everything else your security team monitors.

When a self-hosted platform is more than you need

Self-hosting moves operating work to your team. Before you take that on, check whether the requirement is narrower than it sounds.

Only the credentials have to stay inside
If your review accepts a vendor-hosted control plane as long as applies run on your network, a SaaS platform with self-hosted runners is simpler to operate.
The requirement is Terraform execution and state
If what must stay inside is Terraform runs, state, and policy, and developers are happy working with workspaces, Terraform Enterprise may cover it.
A hosted platform passes your review
Massdriver also runs as a hosted service. If your data rules allow it, the hosted version removes the install and the upgrades from your plate.

Massdriver in two minutes

A two-minute overview of the platform. The self-hosted install runs the same platform inside your environment.

Self-hosted IDP questions

No. Self-hosted runs the full Massdriver platform: the catalog, policy checks, attribute-based access, approvals, the environment graph, and the audit log.

No. Infrastructure state, secrets, deployment history, credentials, topology, and audit records stay inside your environment.

Yes. Self-hosted Massdriver has no dependency on outside SaaS services and runs in disconnected and classified environments.

Your team does. You run the Helm chart, so you choose when to upgrade, and you monitor it with the tools you already use. The CLI and the Terraform provider version independently of the chart.

Not for a self-hosted install that you run. FedRAMP authorizes cloud services that a vendor operates for federal agencies. Self-hosted Massdriver is software you install and operate inside your own authorization boundary, so your assessor reviews it as part of your system’s ATO, against the NIST 800-53 controls they already use.

No. Massdriver manages infrastructure and does not store or process PHI. Teams running HIPAA workloads self-host it so no infrastructure data leaves their environment.

Start with the offer: one hour with your platform and security leads, then a working governed path on your own infrastructure within a day. Qualified organizations can also get a 30-day self-hosted trial license with weekly sessions with Massdriver engineers.

Related reading

Get your platform built.

Give us an hour with your platform and security leads and have a working governed path to production on your own infrastructure within a day, then prove it for 30 days. If you stop, you keep the code.

Get My Platform Built