Your infrastructure. Your database. Your storage.

Acrynite works with database connections and backup artifacts. This page explains how it operates today and what stays in your hands.

Runs locally

A CLI on your machine or server. No Acrynite-hosted service is involved.

Your bucket only

Backup files go only to the S3 bucket or local directory you choose.

Never overwrites

Restores land in a new directory and an isolated container, never the source.

Deployment model

Acrynite is a command-line tool that runs in your environment. Its current CLI workflows do not require a separate hosted Acrynite service, account or dashboard.

  • Local: configuration, the backup catalog, connections to PostgreSQL through pg_dump, pg_basebackup and psql, the scheduler daemon, the recovery directory and the Docker recovery container.
  • Remote: uploads to and downloads from the S3 or S3-compatible endpoint you register, using AWS credentials.
  • On the database server: when WAL archiving is enabled, PostgreSQL's archive_command calls the Acrynite executable, so it and its configuration must be present there.

Database credentials

Connection details are set with acrynite database register. Local configuration and the backup catalog live under storage/configs/ in the working directory.

The current documentation does not describe encryption of stored configuration. Treat the configuration directory as sensitive, and do not assume credentials are encrypted at rest.

  • Restrict the configuration directory with operating-system permissions so only the account running Acrynite can read it.
  • Avoid --password, --access-key and --secret-key where shell history is retained. database show never displays the password.
  • Prefer the AWS credential chain, such as an IAM role or shared profile, over keys stored at registration.
  • Use a dedicated backup role with only the privileges it needs, and rotate it by re-registering the profile.

Backup data handling

  1. Created by PostgreSQL's own tools on the machine running Acrynite.
  2. Transferred to the destination named for that run: an S3 bucket or a local directory.
  3. Recorded in a manifest stored beside the artifact and in the local catalog.
  4. Restored by downloading into a new local recovery directory, then starting an isolated container or importing into a separate profile.

When you configure a remote storage provider, backup artifacts and WAL segments are transferred to that provider. They are then subject to its access controls, encryption settings and policies.

Encryption

The current release does not document built-in encryption of backup artifacts. Acrynite makes no claim of end-to-end encryption, zero-knowledge storage or encryption by default.

  • In transit: use --ssl-mode require or stricter for PostgreSQL connections. S3 traffic uses the HTTPS endpoint you configure.
  • At rest: enable server-side encryption on your bucket, and use encrypted disks for local backup directories.
  • Keys: are managed in your storage provider, not by Acrynite.

This section will be updated if Acrynite adds its own encryption.

Your responsibilities

Acrynite helps you run backups and restores. You remain responsible for:

Securing database credentials.
Restricting access to backup storage.
Configuring appropriate storage permissions.
Monitoring backup and WAL archiving failures.
Retaining sufficient backup and WAL history.
Testing restoration procedures.
Maintaining compatible PostgreSQL environments.

Successful recovery depends on valid backups, available WAL where required, correct configuration and a compatible recovery environment. Test restores regularly.

Reporting a vulnerability

Please report security issues privately through GitHub's private vulnerability reporting. Do not post sensitive details in the public issue tracker.

Report privately on GitHub →