A product-shaped cloud

Your app deserves more than a pile of infrastructure.

Monopod puts applications, hosts, deployments, DNS, secrets, storage, jobs, mail, and managed services in one coherent control plane. Run it with us or run it on infrastructure you control.

Request early access See how Monopod works

Hosted access is paid and invite-only during launch.

1
Start with one server.

Grow into managed k3s and multiple providers when the product asks for it.

2
Keep the evidence.

Releases, operations, health, routes, backups, and failures remain inspectable.

3
Own where it runs.

Choose Monopod-operated hosting or infrastructure under your control.

The infrastructure pile-up

A product starts simple. The platform around it does not.

First there is an app on a server. Then there is TLS. A database. A background worker. Secrets. Object storage. DNS. Backups. Mail. Another host. A deployment pipeline. Someone needs to know what failed at 2:13 yesterday morning.

Soon, the product lives inside a loose collection of provider consoles, shell scripts, dashboards, YAML, notes, and institutional memory. Every piece may work. The whole thing still does not feel like a system.

Small teams are told to solve this by adopting a bigger cloud or hiring a platform team. But raw infrastructure is not the same as an operating model. More primitives often produce more seams.

Monopod begins somewhere else: describe the product foundation in one place, preserve the exact release and runtime evidence, and let focused runtimes do the work. The application stays the center of the story.

01

Ship the release, not a mystery command.

A deployment should connect the source, resolved image, immutable release, configuration, target, operation, health, endpoint, and public route.

Monopod keeps that thread intact. Apply, status, preload, decommission, and rollback belong to an exact deployment ledger—not to whatever happens to be current when a job runs.

Release artifactsexact and immutable
01
Application sourceRepository, environment, workload intent
resolved
02
StackReleaseFrozen workload membership and outputs
created
03
Deployment operationTarget, owner, adapter, and runbook identity
applied
04
Endpoint and routeHealth evidence, hostname, ingress, and TLS
passing
02

Run here. Run there. Keep the same product model.

Begin on one host. Move to a durable managed-k3s target. Use public-cloud VMs where they help, private infrastructure where ownership matters, and Monopod-operated hosting when you do not want to become the operator.

Runtime placement is explicit. Tenant workloads stay tenant owned. The control plane knows what it may operate and where.

Runtime targetsportable by design
Managed k3s

Production-like tenant namespaces and cluster routing.

tenant workload
Private hosts

Monoctl-backed host and hypervisor runbooks.

customer owned
Public providers

Provider-aware compute, networks, volumes, and lifecycle.

API managed
Monopod hosted

A managed foundation for teams that want the product, not the platform duty.

operated for you
03

Domains, TLS, and secrets belong with the app.

A public hostname is not an afterthought. Neither is the secret that gives a workload access to a database or bucket.

Monopod connects DNS intent, authoritative publication, ingress, certificate intent, application configuration, service accounts, and the exact runtime receiving them.

Production routessource of truth connected
monopod.ioInformational site · production
DNS → TLS → Ingress
app.monopod.ioInstallation control plane
DNS → TLS → Control plane
api.product.exampleTenant application API
DNS → TLS → Workload
AppConfig deliveryExact service account and sealed configuration
Vault → Runtime
04

When something happens, leave a trail.

Operations should not disappear into a spinner. Jobs, provider operations, runbooks, callbacks, webhook evidence, deployment events, backups, and restore results remain attached to the resource that caused the work.

That makes retries safer, failures explainable, and production less dependent on the memory of whoever was awake.

Operation logdeployment apply · completed
02:13:04operation frozen with exact deployment target
02:13:05verified tenant execution owner
02:13:05pulled pinned image digest
02:13:07applied workload in tenant namespace
02:13:11endpoint health check passing
02:13:12ingress route reconciled
02:13:13deployment active · evidence retained

The whole product foundation

The things around your app are part of the product too.

Monopod brings the platform primitives into one ownership and operating model without pretending they are all the same runtime.

A
Applications
Environments, workloads, releases
D
Deployments
Targets, operations, health
N
DNS
Zones, records, publication
S
Secrets
Vaults, AppConfig, delivery
O
Object storage
Buckets, keys, durable bytes
P
PostgreSQL
Typed lifecycle and backups
Q
NATS
Cluster intent and operations
M
Mail
Inbound and outbound runtime
J
Jobs
Schedules, execution, replay
C
Compute
Provider and private hosts

Why Monopod exists

Infrastructure should make a product sturdier, not harder to understand.

Hey there—

There is a wonderful moment at the beginning of a project when the whole thing fits in your head. The application has a job to do. The server runs it. The domain points to it. You can explain the system without drawing a wall-sized diagram.

Success slowly changes that. Useful products acquire databases, queues, buckets, certificates, secrets, background jobs, mail, providers, backups, deployment targets, and people with different responsibilities. Each addition is reasonable. Together they can make the product feel less owned.

Monopod is an attempt to keep that original clarity as the system becomes real. It gives every important thing an owner, every deployment an exact release, every operation a durable trail, and every workload an explicit place to run.

It is also built around a simple freedom: managed when you want it, self-hosted when you need it. The operating model should survive that choice.

We are starting with real workloads, careful launch evidence, and a small group of early customers. That is slower than pretending everything is finished. It is also how infrastructure earns trust.

— Monopod

Ways to use Monopod

Four launch offers. No mystery bundle.

Choose who operates Monopod, then add TalkTalkTalk separately if it fits. Exact launch pricing will be published from the authoritative catalog after the paid production flow passes.

Monopod Personal

For individual, non-commercial projects on infrastructure you operate.

Self-hosted

Monopod Business

The business platform operated by Monopod for teams that want managed hosting.

Hosted

Monopod Business Self-hosted

The commercial platform on infrastructure controlled by your business.

Self-hosted

TalkTalkTalk

A separate hosted communication product on the same Monopod account.

Hosted

Hosted launch access is paid and invitation-only. There is no free hosted tier and no initial Monopod/TalkTalkTalk bundle.

Good questions

Before you hand it a real workload.

Infrastructure deserves direct answers.

Is Monopod a managed service or self-hosted software?

Both. Monopod Business can be operated by Monopod or installed on infrastructure controlled by the customer. Monopod Personal is a self-hosted path for individual, non-commercial use. The control-plane model is designed to remain recognizable in either mode.

Does it require Kubernetes?

No. Monopod can begin with a seed host and has direct host and Compose capabilities. The production-like hosted direction uses managed k3s with tenant-scoped namespaces because that is the topology Monopod intends to operate at launch.

Is this Terraform?

No. Monopod records product intent, ownership, operations, and evidence. Its provider layer uses imperative APIs with plans and safety checks, while monoctl handles explicit host runbooks. It does not introduce Terraform state files or pretend to be a general infrastructure dependency graph.

Can I bring existing infrastructure?

That is part of the design. Public-provider resources, VPSs, private hosts, and customer-operated installations can participate through exact provider accounts, compute groups, deployment environments, and execution owners rather than an anonymous host list.

How do signup and billing work?

The public site explains the product, but app.monopod.io owns accounts, invitation-gated signup, authentication, exact offer selection, Stripe Checkout, and subscription state. The marketing page never invents a price or entitlement.

Can Monopod host its own marketing site?

Yes. For the initial one-host launch, the installation serves this informational site at monopod.io and the control plane at app.monopod.io. A later tenant-owned marketing deployment can move the site onto its own compute group without changing the control-plane boundary.

Is production open today?

Not yet. The launch is correctness-first and invitation-only. Production remains gated on the exact deployment, domain, provider, artifact, and paid-onboarding evidence recorded in the project launch plans.

Bring one real workload.

A domain. An application. A host. A deployment that has become too important to live in a pile of scripts and good intentions.

Request early access Sign in to the control plane