Drydock · single-tenant Kubernetes, inside your boundary

You already hold the
authorization.
Drydock deploys inside it.

Drydock is a single-tenant Kubernetes application platform that installs into the AWS account and network boundary you already operate. Nothing is shared with another tenant: your cluster, your data services, your keys. Your developers get a place to hand over source code and get a running application. Your assessors get one more workload inside a perimeter they have already reviewed, rather than a new system asking for its own accreditation. And the deliverable is not a repository of YAML — Orion installs it, validates it, and does the day-2 work alongside your team.

Scope a deployment How it installs ↓
// What it is

Deploy inside the authorization
you already hold.

Standing up a new authorization is a multi-year program: find a sponsor, write the system security plan, then wait in a queue you do not control. Drydock is built to avoid that path.

It deploys single-tenant into an account and network boundary that is already authorized, so the platform arrives as one more workload inside a perimeter your assessors have already accepted, and the heavy controls — physical, media, infrastructure-layer incident response and contingency — stay inherited from what you already run. Drydock holds no authorization of its own and does not ask you to obtain one for it. The authorization stays yours; the platform runs inside its scope.

Single tenancy here is the shape of the platform, not a label on a pricing tier. Every deployment is its own Kubernetes cluster, its own control plane, and its own data services, running in your account under your keys. There is no shared data plane behind it and no other tenant's traffic for an assessor to unpick — which is precisely what makes boundary residence possible. A multi-tenant service would have to carry its own authorization no matter how well it was documented. A single-tenant deployment can be one more workload inside yours.

// How it compares

Three ways to give your
developers a place to deploy.

Capability
Drydock
Shared managed PaaS
Self-managed Kubernetes
One cluster per customer, no shared data plane
✓ Yes
✗ No
✓ Yes
Runs in your AWS account and network boundary
✓ Yes
✗ No
✓ Yes
Can run inside an authorization you already hold
✓ Yes
✗ No
✓ Yes
Vendor holds no credential into the running system
Yes — verified under test
✗ No
No vendor involved
Developers deploy from source, no Kubernetes
✓ Yes
✓ Yes
You build it
Dedicated Postgres, Redis, storage, search, queues
✓ Yes
Shared tenancy
You build it
Control matrix against NIST 800-53 Rev 5
Yes — 325 controls
Varies by vendor
You write it
Day-2 operations
Orion operators
Vendor
Hire a platform team

What we retain: nothing.

The cluster authenticates against your identity provider, not ours. When the install finishes there is no Orion credential and no Orion administrator inside the running system — an Orion operator reaches it the same way your own staff do, through an account you issue and can revoke without asking us. That is verified by testing the finished environment rather than asserted in a policy document, because it is the first question a security reviewer asks about an in-boundary vendor and the last one you should have to take on trust.

On “self-assessed”.

The control matrix is ours rather than a third party's, and that is the design, not a gap we are working toward. Drydock holds no authorization of its own and is not seeking one — the whole model is to run inside yours. So the matrix does the job that model actually requires: for each control at the application-platform layer it states what the platform does, what the hosting environment provides, and what your team still owns, in the format your assessors already read. A third-party certification of a platform that carries no authorization would attest to something nobody is relying on. What the matrix is not is published: it is shared under agreement, and reissued after live validation rather than ahead of it.

// Batteries included

Managed services,
one command away.

Create a service, bind it, and the credentials appear inside your app. No cloud consoles, no tickets, no glue scripts to maintain.

DATA

Databases & caching

Managed Postgres and Redis, provisioned and encrypted, dedicated to you. Backup and restore are operator-run today rather than self-service.

SEARCH

Search & analytics

Managed OpenSearch for full-text search and log analytics, provisioned through the same path and torn down as cleanly as it was created.

STORAGE

Object storage

Buckets for files and assets, provisioned per environment and bound to your app with credentials delivered to the running process.

MESSAGING

Queues

Durable message queues for background and async work, bound to your app in one step — no broker for your team to run.

One login runs the whole platform — developers push apps and operators administer environments with the same corporate sign-in. Policy guardrails and monitoring are built in, not bolted on.

// How it works

From zero to your first deploy
in three steps and one conversation.

The POC starts free. Provisioning the environment is on us. Your team owns the apps you push to it.

01

Scope

A call about the account and network boundary you already operate, the workloads you want on it, and whether Drydock fits. If it does not, we say so on that call.

02

Install

An automated deploy brings up a complete single-tenant environment in your AWS account: the cluster, dedicated data services, networking, and TLS. Nothing is hand-built and nothing is configured through a console, so the environment you get is the one we can rebuild on demand.

03

Validate

The environment is verified end to end before a developer ever touches it: sign-in resolves against your identity provider, the data services answer, and the platform checks itself against the running system rather than against a plan. A first deployment runs with an Orion operator present. It is not hands-off yet, and we would rather say so now than discover it together in your account.

04

Operate

Hibernate and wake are single commands, so an idle environment costs a fraction of a running one. Teardown removes the environment and returns the account to zero spend — confirmed against live billable-resource counts rather than the teardown script's own report, because a check that grades its own work is not a check. Deploy-to-teardown cycles are run regularly, and a teardown can still need an operator on it, which is why we run it with you rather than handing over a script and wishing you luck.

// Questions worth asking

Honest answers,
before the contract.

Is Drydock FedRAMP authorized, or does it hold an ATO?
No. There is no FedRAMP authorization, no ATO, and no third-party assessment behind it — the whole model is to run inside yours. Drydock deploys into an account and network boundary you already operate, so the platform arrives as one more workload inside a perimeter your assessors have already accepted, and the heavy controls stay inherited from what you already run. The authorization stays yours.
Has it been deployed into a customer environment yet?
Not into a customer account — Drydock is built and ready for engagement, and what it does not carry yet is a customer reference. The full single-tenant shape has been deployed end to end against a customer-shaped environment and validated there: the platform came up inside an account boundary it did not own, sign-in resolved against that environment's own identity provider with no Orion credential anywhere in the finished system, and the service marketplace was exercised from the command line. Deploy-to-teardown cycles run repeatedly. A first deployment runs with an Orion operator present — not as a caveat, as the offer.
What documentation do assessors get?
A control-responsibility matrix in the format federal platform teams already read: for each control at the application-platform layer, what the platform does, what the hosting environment provides, and what your team still owns. It is written against NIST 800-53 Rev 5, covers roughly 325 controls, and sits alongside incident-response and contingency plans written against NIST 800-61 and 800-34. Two things it is not: it is self-assessed rather than third-party assessed, and it is private — shared under agreement, not published. The document has to trail the running system rather than lead it, so we reissue it after live validation, never before.
What is not built yet?
Autoscaling is designed but not built. Custom domains are not available. Backup and restore are operator-run today, not self-service, and we have published no recovery-time commitments; those get written with the first design partner, against their requirements, rather than invented in advance. There is no committed uptime number. The GovCloud port is scoped and not started — the platform runs in commercial AWS today.
What does it cost?
The infrastructure floor for a running environment is roughly $400 a month, about $110 hibernated, and zero destroyed. The zero is confirmed against live billable-resource counts — EKS, RDS, cache, load balancers, NAT, unattached volumes — rather than a script's exit code, because those are the two things that can disagree. Our fee sits on top and is a conversation, not a signup page.
Do developers need to know Kubernetes?
No. They hand the platform source code; it detects the language, builds it, runs it, and keeps it running. No container images to author, no Kubernetes objects to write, no cluster knowledge required at any step. Streaming logs and real per-instance metrics come with it, and memory scaling is a single command.
How does this relate to Sprintsail?
Sprintsail is the same Kubernetes platform, operated by us as a managed service. Drydock is the version that ships into your boundary. If you would rather we host it than install it in your account, start there instead.
// Dive deeper

Notes on the platform.

Public sector

NYC's $600K AI chatbot — why government technology projects fail.

Read →
PaaS

The best Heroku alternative in 2026 — including one that runs in your own AWS account.

Read →
Shortlist

SME review in hiring — why a senior in the room beats another screening round.

Read →
Ark

AWS CDK consulting: what it is, when you need it, and what to expect.

Read →
// Also from Orion

Built, run, and sold by the same team.

$ push
// Sprintsail

The same platform, operated by us

If the platform does not need to live inside your own boundary, Sprintsail is the managed version: push source, get a running app, with databases, storage, and queues attached. Nothing to install and nothing to operate.

  • Source to running app · no Dockerfile · no YAML
  • Managed databases, storage, and queues
  • Live logs · per-instance metrics · console or CLI
See Sprintsail →
~/shortlist
// Shortlist

A standard for engineering ability

A verification engine: a senior-reviewed bar for what good means in a domain, and the verified pool that bar produces — feeding Orion's teams, partners, and recruiter rails.

  • Assessment · lab · live session — proof, not claims
  • Human sign-off · no model decides alone
  • Internal teams · partners · recruiter rails
See Shortlist →
// Get started

Request a free POC.

Tell us about your workload. We will provision a dedicated Drydock environment for your team within 24 hours.

Start a POC Talk to engineering