Home / Operate

Ownership without mystery

Run a backend your team can own, change, and recover.

Choose where Daptin runs and where its data lives. Keep customer records, files, background work, and connected services visible as one operating responsibility—so your team can answer what is healthy, what is failing, and how to bring the product back.

Plan your production path Explore deployment choices

Choose Run on infrastructure that matches your product. A versioned container or release binary, with a database and storage you select.

See Follow the customer paths that matter. Health, logs, queues, limits, storage, and dependencies—not just a green process.

Recover Restore the whole application context. Records, files, configuration, keys, certificates, and connected-service credentials.

The operating idea

Self-hosting should create control, not guesswork.

Daptin brings many recurring backend jobs into one application server. That reduces the number of separate services your team must connect, but it does not make production responsibility disappear.

The useful trade is clarity. You choose the database, storage, network edge, secrets, capacity, and backup policy. Daptin gives those choices one product context: the same customer path may touch a record, an attached file, a scheduled action, and an outside provider.

This page starts with the decisions a product owner or operator needs to understand. Exact configuration keys and deployment commands remain in the technical reference once the operating shape is clear.

A production journey

Move from “it runs” to “we can rely on it.”

Treat production as a sequence of promises your team can verify and repeat.

01 · Place it Choose the home.

Pin a release, select a database, decide where files live, and put a trusted network edge in front.

02 · Protect it Define the boundary.

Create administrators privately, manage secrets and certificates, restrict origins and services, and test real user access.

03 · Watch it Observe real journeys.

Check sign-in, protected records, file delivery, scheduled work, and provider calls alongside process health.

04 · Bring it back Rehearse recovery.

Restore data, assets, keys, and configuration away from production and prove the product still works.

What your team gains

Operations stay connected to customer experience.

The most useful operating signal is not “the server is up.” It is “the work customers depend on still completes.”

Fewer seams to diagnose

Records, permissions, files, actions, live updates, and scheduled work share one application context. An investigation begins closer to the product problem.

Monitoring and health →

Capacity choices you can name

Set boundaries for requests, uploads, connections, background work, database use, and traffic before overload chooses them for you.

Traffic controls →

State you can account for

Know which records, assets, settings, credentials, and certificates must move together during backup, restore, or migration.

Configuration →

Choose a shape

Start with the level of control your team can support.

The package is the easy part. Persistent state, secure exposure, upgrades, and recovery determine whether a deployment is ready for customers.

Versioned container

A good fit when your team already operates containers. Pin the image, mount persistent state, pass secrets safely, add resource limits, and keep the previous artifact available.

Release binary

A direct fit for a single host or service manager. Give the process a dedicated identity, durable directories, supervision, log rotation, and an explicit rollback path.

Source build

Useful for auditing or maintained internal changes. Your team also owns the toolchain, reproducibility, dependency review, and the cost of carrying a fork.

Small starts are valid. SQLite and local files can make evaluation straightforward. Before the product grows, decide whether their durability, concurrency, backup, and restore characteristics still fit.

Protect the product

Security follows identity from the edge to the record.

There is no single switch that makes an application safe. The goal is a short, understandable chain of trust.

Who is this?

Establish a trustworthy identity.

Keep initial administration private, choose sign-in methods deliberately, protect session and signing material, and test account recovery.

Authentication Two-factor sign-in

May they do this?

Let access follow the actual work.

Review table, record, relationship, file, and action access with representative customer identities—not only an administrator.

Permissions Audit history

What is exposed?

Open only the surfaces the product needs.

Put TLS at a trusted boundary, restrict origins and proxy trust, and decide whether mail, FTP, DAV, metrics, or profiling should be reachable at all.

Certificates Protocols

What can leave?

Control connections to outside providers.

Review provider definitions, destinations, permissions, credential owners, and the identity used when an integration performs work.

Credentials Integrations

Observe the promise

Monitor what a customer would notice.

A health response proves the process can answer. It does not prove a customer can sign in, read a protected record, download a file, receive an email, or see scheduled work complete.

Choose a few representative journeys and check them from outside the process. Combine those checks with structured logs, database and storage health, queue age, repeated provider failures, and capacity signals.

Protect diagnostic data as carefully as product data. Keep sensitive values out of logs and make profiling available only to trusted operators for limited periods.

See how Daptin exposes health and runtime evidence →

Recovery

A backup is only real after the product returns.

A database-only copy can leave files, credentials, certificates, or scheduled behavior unusable. Recover the application as one state.

List everything the product needs.
Database records, local or remote assets, settings, encryption and signing keys, certificates, provider credentials, and the pinned release artifact.
Back up on a schedule the business understands.
Set an acceptable amount of lost work and an acceptable recovery time, then make retention and frequency match those promises.
Restore somewhere isolated.
Avoid learning the process during an incident. Practice without risking the live environment.
Prove representative journeys.
Sign in, read protected data, deliver an asset, run an action, and check a provider or protocol path before declaring recovery successful.

Honest boundary

Daptin is self-hosted software, not an operations team.

Daptin gives you a broad connected backend and the controls to run it. Your team remains responsible for infrastructure, database and storage durability, secrets, DNS, TLS, provider terms, capacity, monitoring, incident response, upgrades, and tested recovery.

Production guidance on this site is pinned to release v0.12.36. Later source includes additional lifecycle and Kubernetes-oriented work; evaluate that separately until it appears in a published release.

Open the production reference ↗ Inspect the release ↗

Make ownership concrete

Choose the data, deployment, and recovery path before customers depend on it.

Then use Daptin’s operating features to keep that responsibility visible.

Explore deployment Choose a database path