Home / Operate

See the database, storage, queues, dependencies, limits, logs, and recovery procedures your team operates.

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

Choose where Daptin runs and where its data lives. Monitor sign-in, file delivery, queue progress, storage, database access, and provider calls; recover each path from a tested runbook.

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. Check health endpoints, structured logs, queue age, resource limits, storage reachability, and dependency status.

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

The operating idea

Use explicit deployment settings, health checks, logs, backups, and rollback procedures to operate the self-hosted instance.

Daptin brings many recurring backend jobs into one application server. Daptin consolidates backend services while your team owns deployment, monitoring, backups, upgrades, and recovery.

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.

Test customer sign-in, protected reads, file downloads, email delivery, and scheduled work alongside process uptime.

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.

Layer TLS, strong secrets, least-privilege permissions, request controls, monitoring, backups, and tested recovery. 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.

Test table, record, relationship, file, and action access with representative customer accounts and administrator accounts.

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. Run synthetic checks for customer sign-in, protected reads, file downloads, email delivery, and scheduled completion.

Choose a few representative journeys and check them from outside the process. Combine workflow checks with structured logs, database and storage health, queue age, provider status, and capacity metrics.

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 recovery-point and recovery-time targets, then configure backup frequency and retention to meet them.
Restore somewhere isolated.
Rehearse backup restoration, rollback, credential rotation, and dependency recovery before an incident. Run restore and rollback drills in an isolated environment that matches production data volume and configuration.
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

Your team deploys, monitors, backs up, secures, scales, and upgrades each Daptin instance.

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 follows Daptin’s published documentation, standards-based interfaces, and current release artifacts.

Open the production reference ↗ View current releases ↗

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