Productify

Appearance

data ​

pfy data declares and operates an application's managed data stores: the PostgreSQL and Redis instances the platform provisions for you. list/create/update/delete edit the declaration; status, backup-now, restore, and regenerate-credentials act on the running instance in one environment.

Synopsis ​

bash
pfy data <subcommand> [flags]

Description ​

An application declares that it needs a postgres or a redis, and the platform provisions it: one Nomad job per (data store, environment), credentials generated at apply time and written to Nomad variables (never shown, never stored in the Manager), and connection URLs injected into the stack's services (unless a service opted out with inject_data_env = false).

Backups are on by default for postgres: when you create a postgres store without any backup flags, the Manager seeds a daily schedule. Backup destinations are named backup targets declared by the operator in install.yaml; the target field carries no URL, path, or credential.

Target flags ​

All subcommands share the service target flags (--app, --env/-e, --project, --project-id). Several also take:

FlagDescription
--tenantOperate on the store belonging to this tenant's dedicated stack
--namespaceNomad namespace override. The namespace is normally derived from the environment; a value that does not match it is refused

--env is required on instance commands, and it fixes the namespace

status, backup-now, restore, and regenerate-credentials act on one (store, environment) instance, so they require --env. The alias must exist in project.yaml and carry an environment_id (pfy sync or pfy env link write it); the CLI then reads the Nomad namespace from that environment's deployments. You do not need --namespace. If you pass it and it differs from the derived one, the command stops with environment "prod" runs in Nomad namespace "x", but --namespace "y" was given.

data list ​

List an application's managed data stores (the app-level declarations).

bash
pfy data list --app myapp --project my-saas
main                 postgres   postgres:16      0 3 * * *
cache                redis      redis:7          (no backups)

Server-side warnings (e.g. "postgres without backups") are printed verbatim under each store.

data status ​

Show each store's instance, run state, and backup policy for one environment (--env required).

bash
pfy data status --app myapp --project my-saas --env prod [--tenant <slug>] [--namespace <ns>]
main                 postgres  postgres:16      myapp--main
  state    running
  backups  0 3 * * * -> nightly, keep 14 (myapp--main-backup: running)

Structured output: pfy -o json data status ….

data create ​

Declare a managed data store for an application.

bash
pfy data create <slug> --app <app> --kind postgres|redis --version <tag-line> [spec flags]
FlagRequiredDescription
--kindYespostgres or redis; immutable after create
--versionYesImage tag line to pin (e.g. 16 for postgres, 7 for redis), not a full image reference
--cpuNoCPU reservation in MHz
--memoryNoMemory reservation in MB
--volumeNoNomad host volume the data lives on
--sizeNoCapacity hint, e.g. 20G (documentation, not an enforced quota)
--backup-scheduleNoCron schedule for the backup job; postgres defaults to a daily backup when unset
--backup-targetNoName of a backup target declared in install.yaml under backup_targets; no URL, no credential
--backup-retentionNoHow many dumps to keep before the oldest is pruned

Example ​

bash
pfy data create main --app myapp --project my-saas --kind postgres --version 16 \
  --backup-target nightly --backup-retention 14
Created postgres data store main (postgres:16)
Backups: 0 3 * * *

data update ​

Edit a store's version, resources, storage, or backup policy. kind and slug are immutable (they name a live instance's job, image, and credential path); recreating the store is the deliberate path.

bash
pfy data update <slug> --app <app> [spec flags] [--clear-backup-schedule]

--clear-backup-schedule turns backups off for the store (mutually exclusive with --backup-schedule; for postgres this is reported as a warning, not refused).

Example ​

bash
pfy data update main --app myapp --project my-saas --version 17

data delete ​

Delete a managed data store: removes the app-level declaration (across every environment), the job, and the generated credentials.

The volume is NEVER deleted automatically. The data stays on disk, and once the record is gone nothing in the platform describes what that volume held. The warning printed before the prompt names the actual volume.

bash
pfy data delete <slug> --app <app> [--yes]

On a TTY you must type back the qualified label <app>/<store> (e.g. myapp/main); a bare main is no confirmation, since every application has one. --yes/-y skips the prompt and is required under --ci or without a TTY.

data regenerate-credentials ​

Rotate a store's generated password and restart the jobs that use it: the store first, then every service that injects its connection URL. The restart is not optional: credentials are resolved at task start-up, so without it nothing would actually change. Connections fail between the store restart and its consumers'.

The store is waited for before any consumer is bounced: a consumer restarted early would reconnect with a password the database has not adopted yet. If the store does not become healthy within two minutes the command stops there and says so, leaving the consumers on their old connections rather than breaking them; restart them by hand once the store is up. Both kinds rotate (postgres adopts the new password through the reconcile step its job runs at start-up); an unrecognised kind is refused before anything is written.

bash
pfy data regenerate-credentials <slug> --app <app> --env <env> [--tenant <slug>] [--namespace <ns>] [--yes]

--env is required: a credential belongs to one (store, environment) instance. The typed confirmation label is the qualified instance name <app>/<env>[/<tenant>]/<store>. The new password is written to the store's Nomad variable and is never displayed or stored in the Manager. Services with inject_data_env off are skipped.

Wrote a new credential to <nomad variable path>
Restarted myapp--main, myapp, myapp--api

The --namespace help text for this command says "default: the cluster default", but the namespace is derived from --env exactly as for the other instance commands.

data backup-now ​

Run a store's backup job immediately, out of schedule. The registered periodic job is forced (the same job the schedule runs), so the store must have a backup schedule and the stack must have been applied (pfy nomad deploy --stack).

bash
pfy data backup-now <slug> --app <app> --env <env> [--tenant <slug>] [--namespace <ns>]
Dispatched myapp--main-backup. Follow it with `nomad job status myapp--main-backup`.

data restore ​

Restore a data store from a dump, stopping and restarting its dependents around the restore.

bash
pfy data restore <slug> --app <app> --env <env> --from <dump-file> \
  [--install install.yaml] [--tenant <slug>] [--namespace <ns>] [--wait-timeout 30m] [--yes]
FlagRequiredDescription
--envYesThe (store, environment) instance being restored
--fromYesThe dump file to restore, as it appears in the store's backup target (e.g. myapp--main-20260101T030000Z.dump)
--installNoPath to install.yaml, whose backup_targets the store's backup.target name resolves against (default: install.yaml)
--wait-timeoutNoHow long to wait for the restore job (default: 30m); the dependents stay stopped until it finishes. Not the global --timeout, which is the per-request HTTP timeout

What it does, in order:

  1. Prints what will happen: the restore replaces the store's current contents (which are not backed up first), and names the services that will be stopped for the duration.
  2. Requires the qualified typed confirmation <app>/<env>[/<tenant>]/<store> (or --yes; --yes is mandatory under --ci/non-TTY). Nothing is touched before the confirmation.
  3. Stops every dependent service (services that receive this store's connection URL; opted-out services are skipped). For redis, the store itself is also stopped, because a running redis would rewrite the snapshot from memory on shutdown. Postgres is restored over the wire and stays up.
  4. Runs the rendered restore job and waits for it to complete.
  5. Starts everything back: the store first, then the dependents in their original order. If the restore failed, the store's previous contents may be partially replaced; the error says so explicitly, so do not treat the store as restored.

Example ​

bash
pfy data restore main --app myapp --project my-saas --env prod \
  --from myapp--main-20260721T030000Z.dump
Stopped myapp
Stopped myapp--api
Restored data store main from myapp--main-20260721T030000Z.dump.
Started myapp
Started myapp--api

See Also ​