Skip to content

Operations Guide

This guide covers operational procedures for running Enprivacy 3.0, including backup, restore, and reference RTO/RPO targets.

Backup and recovery is your responsibility as the operator. The following outlines the recommended backup scope and frequency.

Component Description
Application database Primary data store (user data, workspace config, audit logs)
Object / blob storage Uploaded files and attachments
Application configuration Environment variables and secrets (back up separately and securely)
Component Recommended frequency
Application database TODO
Object / blob storage TODO

These are reference targets for typical reference architectures. Actual values depend on your infrastructure and backup configuration.

Architecture RTO RPO
Single-node (development) TODO TODO
High-availability (production) TODO TODO

The service connects to PostgreSQL using a database user with privileges over the application schema. For improved security, rotate this user’s password regularly using either a single-user or dual-user configuration. See Database Setup in the Deployment Guide.

The Web, Job and Inference Adapter services need no durable storage for models: the adapter’s models and the platform’s address data are baked into their images, and nothing is downloaded at runtime. See Model data.

A self-hosted LLM caches its models locally; mounting that cache on durable storage speeds its restarts. It needs no backup — it can be repopulated.

The Inference Adapter exposes unauthenticated /health and /ready on its TLS listener; see Start-up and health.

Enprivacy 3.0 emits structured JSON audit logs to stdout. These should be forwarded to your SIEM or log aggregation platform.

See the Deployment Guide for upgrade procedures. A release that renames stored names deploys in a maintenance window instead of a rolling deploy; see Maintenance-Window Upgrades.