Run it your way

Take Daptin from a local evaluation to an environment your team can own.

Use a pinned container or release binary, choose persistent state, put the right services behind a trusted edge, and keep a rollback path.

See what it changes Technical guide ↗

Deployment in a product

Choose the releasePin v0.12.36 and its artifact

Connect durable stateDatabase, assets, configuration, and keys

Expose only the product surfaceProxy, TLS, monitoring, backup, and rollback

Deployment is an owned product decision

01Begin with a repeatable artifactUse a pinned container or release binary.

02Keep state beyond the processPersist database, files, configuration, and key material.

03Prepare for change and failureBack up, observe, upgrade deliberately, and retain rollback.

Why it matters

Starting the process is easy. Owning the product means planning what survives it.

A local container can prove the product quickly. Production adds harder questions: where data and files persist, which services are public, how secrets and TLS are managed, how health is observed, and how an upgrade can be reversed.

Daptin ships as versioned releases and a container, with Compose useful for evaluation and small coordinated environments. The same runtime can connect to supported external databases and cloud storage.

A production deployment treats the binary as one replaceable piece of a wider owned system. Database, storage, DNS, certificates, monitoring, and recovery must move through change together.

Reproduce what you run

Pin the application artifact and record its configuration.

Separate process from state

Keep durable data, files, secrets, and certificates outside disposable runtime layers.

Make upgrades reversible

Back up first, observe representative paths, and retain the earlier compatible artifact and recovery plan.

How it fits

Part of one connected backend.

Deployment does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Package

Choose the versioned image or release binary.

Step 2Persist

Connect the database and storage appropriate to the workload.

Step 3Protect

Configure secrets, TLS, origins, network exposure, and limits.

Step 4Operate

Monitor, back up, restore, upgrade, and roll back the whole system.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Single-server product

Run the binary under a service manager with externalized state.

Container deployment

Place a pinned image behind an existing proxy and monitoring stack.

Coordinated small stack

Use Compose as a starting point, then replace examples with real secrets and persistence.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes deployment more useful.

Know the boundary

What Daptin leaves in your hands.

Daptin is self-hosted software, not a managed control plane. You own infrastructure, availability, scaling, backups, secrets, DNS, certificates, upgrades, and incident response. Kubernetes work after v0.12.36 is not marketed as a released path.

Understand the operating responsibility →

Build from one foundation

Make deployment part of the product—not another disconnected service.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities