// Solutions

Your deployment control plane. Inside your perimeter.

Some teams cannot or will not put deployment metadata in a SaaS. Jaws Deploy Stack is the same product as Cloud - same workflow, same UI, same agents - running entirely on your hardware, behind your firewall, on your update schedule.

Contact sales Try Cloud first

Why a self-hosted deployment platform exists

Most teams should not self-host their deployment tool. It is one more thing to operate. But for the teams who must - because of regulation, network architecture, or hard-won security policy - the conversation is not 'should we?'. It is 'how do we do this without burning a quarter on the rollout?'.

Jaws Deploy Stack exists for exactly that team. It is the same product as Jaws Deploy Cloud, packaged to run on your hardware. The product model, the UI, the agent protocol, the REST API - all identical. The difference is hosting.

// The first thing to clarify

Self-hosting is a deployment decision, not a different product.

Stack is not a stripped-down or 'lite' version. It is the full platform, with the only meaningful caveat being that you (not us) are responsible for keeping the control plane alive. Most teams that adopt Stack first try Cloud, validate the workflow, then deploy Stack with a clear picture of what they are putting into their environment.

Same projects, releases, environments, variables, agents.
Same UI. Same REST API. Same PowerShell SDK.
Same upgrade cadence - you choose when to apply each update.

Who actually needs this

Being honest about fit is more useful than being optimistic. The teams that buy Stack tend to share three or four properties.

The shape of a self-hosted buyer

Regulated industry Finance, healthcare, defense, public sector, critical infrastructure. The reason isn't always written down - sometimes it's an interpretation of an audit standard that you can't argue with.

Air-gap or restricted network Production cannot reach the public internet. Deployment automation must run inside the same network. There is no SaaS path here, regardless of policy.

Data-residency requirements Deployment metadata (variable names, project structure, release notes) is itself considered sensitive. It cannot leave a specific jurisdiction or tenant.

Custom update control You need to schedule platform updates with the rest of your change-management process. You cannot accept a vendor pushing updates on their schedule.

What the self-hosted deployment looks like

Stack is delivered as a set of containers and binaries you install on your own infrastructure. The control plane runs on whatever VM or Kubernetes setup your team standardizes on. Agents are exactly the same as on Cloud - they call outbound to the control plane, which now happens to be one of your servers instead of ours.

// The reference deployment

What 'install Stack' actually means

Control-plane host - one VM or a small cluster, depending on team size. The control plane handles the API, UI, scheduling, and persistence.
Database - your existing MySQL or PostgreSQL instance. We don't ship a database; we connect to yours.
Object storage (optional) - for package feeds and large artifacts. S3-compatible, Azure Blob, or local disk if you must.
Identity - OIDC connector to your existing IdP. We do not store passwords; we lean on your auth.
Agents - installed on each deployment target, exactly like Cloud.

// The migration question, asked early

Cloud-to-Stack is a documented migration. Stack-to-Cloud also works.

If you start on Cloud and need to move to Stack later (or vice versa), the data model is identical and a migration path is supported. We don't pretend this is a fifteen-minute job - it is not - but it is also not a 'rebuild the deployment platform' project. Teams that have done both directions report the move as 'a planned weekend'.

Cloud-to-Stack: more common, usually triggered by a compliance milestone.
Stack-to-Cloud: less common, usually triggered by a desire to stop operating it.
The deployment process you built does not need to be rewritten in either direction.

What you take on by self-hosting

It is fair to be direct about the operational cost. We are not going to tell you it is free.

// Your team owns

Operating the control plane

Patching the host, monitoring uptime, sizing the database, rotating certificates, scaling for parallel deploys. None of this is exotic - it's the same stuff you do for any internal service.

// We own

The product itself

Bug fixes, new features, security patches, the agent protocol, the migration scripts between versions. Stack ships with the same release cadence as Cloud.

Security posture, in concrete terms

The security conversation tends to be the most important one in a self-hosted procurement. Here is what we put on the table without prompting.

// The default security posture

Things we make easy to verify or audit

No outbound calls from the control plane. Stack does not phone home. Telemetry is opt-in and clearly named.
OIDC-first auth - we do not store credentials; we delegate to your existing IdP and respect its session management.
Encrypted at rest - secrets in the database use envelope encryption with a key you control.
Encrypted in transit - mutual TLS between control plane and agents, configurable certificate authorities.
Audit log - every state-changing action writes to a structured audit table you can ship to your SIEM.
Air-gap support - including package feeds, agent installation, and platform updates via downloadable bundles.

// A snippet from the docs

How OIDC integration looks in a Stack config

Stack does not invent a user database. It uses yours. Most teams plug it into Okta, Entra ID, Keycloak, or an internal IdP in an afternoon.

# stack.config.toml
[auth.oidc]
issuer        = "https://idp.internal.acme.example/realms/eng"
client_id     = "jawsdeploy-stack"
client_secret = "${OIDC_CLIENT_SECRET}"
scopes        = ["openid", "profile", "email", "groups"]

[auth.oidc.role_mapping]
"group:platform-admin" = "Admin"
"group:platform-team"  = "WorkspaceAdmin"
"group:engineering"    = "Deployer"
"group:everyone"       = "Viewer"

// Compliance, plainly

We can support audits. We do not 'have' your certification.

Stack gives your team the building blocks to meet SOC 2, ISO 27001, HIPAA, FedRAMP, or sector-specific requirements. The certifications themselves are yours - they describe your operation, not ours. We provide architecture documentation, audit log exports, threat models, and direct technical contact during your auditor review. We do not pretend that running our software automatically makes you compliant. It doesn't.

We have detailed documentation for common audit questions.
We will get on a call with your auditor.
We will not sell you a 'compliant deployment platform' as a checkbox.

What to do next

For most teams, the path is: try Cloud first, validate the workflow with a non-production project, then talk to us about Stack pricing and a pilot. Stack pricing is custom to the deployment footprint - we don't run a self-service signup for the self-hosted product because the conversation is always longer than that.

The Cloud trial costs nothing. The Stack conversation usually starts with a thirty-minute call to understand what you are protecting and why. We won't try to talk you out of self-hosting - we will try to talk you into doing it for the right reasons.