# Deploy ParticleDB

Prepare a persistent, authenticated ParticleDB deployment and verify recovery before serving application traffic.

Source: https://particledb.ai/guides/deployment/

## Before deployment

Record the server version, configuration and data location. Choose storage with adequate capacity, configure authentication and TLS, and restrict network access. Test with your application's client versions.

## Start an authenticated instance

Provision a certificate and private key for the database hostname and a password file readable only by the database service account. See [TLS and authentication](/connectivity/tls/) for certificate setup.

```bash
particledb start \
  --data-dir /var/lib/particledb \
  --http-addr 127.0.0.1:7173 \
  --pg-addr 127.0.0.1:5432 \
  --redis-addr 127.0.0.1:6379 \
  --grpc-addr 127.0.0.1:26257 \
  --pdb-addr 127.0.0.1:5440 \
  --metrics-addr 127.0.0.1:7175 \
  --no-unix-sockets \
  --auth-method scram-sha-256 \
  --pg-password-file /etc/particledb/password \
  --tls-cert /etc/particledb/server.crt \
  --tls-key /etc/particledb/server.key \
  --require-tls-for-credentials \
  --wal-sync-mode groupsync
```

This example keeps access local. To accept connections from application hosts, bind only the required client address to a private interface and restrict it with your network policy. The native client address is explicitly restricted to loopback. The MySQL interface remains disabled unless explicitly enabled in configuration.

Run the process under your service manager with a dedicated account, a writable data directory and a defined restart policy. Retain the startup logs and verify a query using your application's TLS settings before directing traffic to it.

## Persistent data

Use a persistent data directory outside temporary storage. Do not run two servers against the same directory. Review [durability and restart](/operations/durability/) and the effects of your configured persistence mode.

## Resources and monitoring

Set [memory limits](/operations/memory/) and [connection limits](/operations/connections/). Configure [monitoring](/operations/monitoring/) and verify that your application recognizes failed health checks and connection errors.

## Recovery

Practice a restore using the backup or export path available in your edition. Check data and schema before directing application traffic to the restored instance. A clean shutdown test does not establish power-loss recovery behavior.

## Upgrade

Read release notes, retain a recovery path, and validate the new binary against a copy of representative data before changing production. See [upgrades](/guides/upgrades/).

## Related

[Documentation home](/docs/) · [Troubleshooting](/guides/troubleshooting/)