MaleusMaleus

Audit, encryption, and operations

Understand audit trails, application-level encryption, observability, messaging, and deployment responsibilities.

In the appApplication · OperationsUpdated September 19, 2026
On this page

The foundation includes operational primitives, but does not conflate deployable code with fully automated operations. Each project confirms its availability, backup, and monitoring objectives.

Keep a business audit trail

The audit trail can record the tenant, actor, action, entity type, entity identifier, a message, a functional tag, and the date. The actor identifier remains available even if the account is deleted.

The record is written to the database and structured logs. It can feed a paginated, filterable administration page for support, compliance, and investigations.

Encrypt sensitive values

Cryptonomicon provides shared authenticated encryption, using AES-256-GCM by default or ChaCha20-Poly1305. Keys are derived with HKDF from a master key, a salt, and a context.

This primitive can protect a provider key stored in the database, for example. It guarantees confidentiality and tamper detection for fields that use it. It does not automatically encrypt every table, file, or infrastructure volume.

Passwords follow a different contract: they are hashed with Argon2 and can never be decrypted.

Correlate a request end to end

Pino logs are structured and enriched with a requestId, route, API action, tenant, user, and, when available, project or version. The context is created before the request body is parsed, preserving a correlation identifier even for invalid JSON.

HTTP errors follow a catalog of codes. Server errors and processing outside requests can be relayed to the configured alert channel. Datadog tracing and runtime metrics are optional.

This foundation makes diagnosis easier, but SLOs, dashboards, and alerting rules still need to be configured for the environment.

Deploy the base runtime

The generated application generally brings together:

  • a frontend served behind a public entry point;
  • an API backend;
  • PostgreSQL;
  • the additional services actually used, such as RabbitMQ, Redis, or S3.

The frontend proxies /api and /sso to the backend. The backend applies migrations, initializes security data, and exposes a health check. Docker images and environment variables provide a portable foundation for cloud or on-premises deployment.

01BrowserThe user's authenticated session
02FrontendSPA, static assets, and proxy for /api and /sso
03BackendAPI, authorization, modules, jobs, and health check
04Data servicesPostgreSQL plus the storage and messaging actually used
One public entry point, separate application services, and explicit dependencies.

Go-live checklist

  1. Build the frontend and backend images in CI.
  2. Check the PostgreSQL extensions required by the project.
  3. Confirm that a backup can be restored.
  4. Start the database and verify its health.
  5. Start the backend and wait for the health check.
  6. Start the frontend and test the API through the public proxy.
  7. Test login, an authorized action, a denial, and persistence after restart.
  8. Check logs, the audit trail, metrics, and alerts.