Operate & maintain
ReadyRunning Ydentifi over the long haul is light work: watch a handful of signals, rotate on a known cadence, and back up one PostgreSQL database — the server handles its own housekeeping. One rule above all: never touch the database directly. Drive everything through ydfi.
Who this is for: whoever keeps a deployment running in production. This is the day-2 view — what to monitor, what rotates when, how to back up and upgrade, and the one thing never to do.
Treat the PostgreSQL database as Ydentifi’s private organ. Every read and write goes through ydfi or the API — never direct SQL. The guarantees that make the system trustworthy — license caps, tenant isolation, and the guarded transactions that keep concurrent writes correct — live in the server, not the schema. A hand-edited row doesn’t just risk data; it can silently void those guarantees. If you need to see or change something and can’t find the command for it, ask us before reaching for psql.
What to watch#
Four signals tell you a deployment is healthy. None needs constant attention — wire them into whatever you already use.
| Signal | Where | Healthy looks like |
|---|---|---|
| Deployment health | ydfi admin health | DB pool ok, certificates valid, reapers running. |
| Metrics | /metrics → Prometheus | Steady request rates, error rates, and latencies. Ships with a Prometheus + Grafana profile. |
| Certificate expiry | boot sweep + GetCertificateExpiry | Nothing inside its warning window — the server logs a warning well before anything lapses. |
| License state | ydfi license status | Active, within your seat count, not near expiry, no license waiting. |
The /metrics endpoint is a standard Prometheus scrape target, so it drops straight into monitoring you already run. Everything the server is doing is visible there and in its structured logs — there is no hidden state.
What runs on its own#
A few background workers keep the deployment tidy without you. Knowing they exist is the point — if ydfi admin health says the reapers are running, this is what’s running:
Expires challenges that were never answered within their TTL and closes their streams, so nothing lingers in flight.
Opaque-token hygiene — clears quarantined and orphaned records on a set interval so the identity store stays clean.
At every boot, checks each serving certificate and the license and logs a warning for anything nearing expiry.
The cyclical worker that keeps usage within your licensed caps and drives the license lifecycle state.
What each of those discards is short-lived operational state the deployment has no further use for. The deployment keeps no history for them to sweep — see below.
Your records, and how long you keep them#
The database holds working state and a seven-day tail of requests. History is in your logs. Every device ceremony — enrolled, replaced, deactivated, revoked, banned, unbanned, deleted with its user — is a device_lifecycle line, and every security-relevant action the server takes is a structured security event. Two device changes are security events instead: a device retired after a year unused is device_marked_stale, and closing a relying party is one admin_delete_rp for all its devices. Both go to the deployment’s log pipeline, wherever that pipeline sends them.
The server writes these lines to standard output and keeps no copy. If nothing captures them, a device’s history and the record of what the server did are gone as they are written. How long the lines live, where they are copied, and who may read them are decisions your logging stack makes, not decisions this product makes for you. If you have a retention obligation, it is met there, the same way it is met for every other service you run.
Closing a relying party removes nothing from your logs. ydfi admin delete-rp removes the tenant and its working state from the database by cascade; the lines it left behind stay for as long as your pipeline keeps them.
What to rotate, and when#
- Certificates — on the cadence set by their lifetimes: server leaves are short-lived (~90 days), relying-party certs last years, the root almost never. The full table and workflows are in Certificates & PKI.
- The license: there is nothing to renew from the server; it never phones home. To renew, run
ydfi pulland install the result withydfi license apply. A running server checks for a new license about once a minute; a license for a different customer is loaded only on restart. If the server runs in a container, mount the directory that holds the license, never the file on its own, or the server keeps reading the old one. Warnings start 7 days before expiry. Requests keep working for 30 days after it, then are refused until a new license is installed. Check standing withydfi license status. - A license with fewer seats than your relying parties reserve: check it first with
ydfi deployment preview-license. A running server keeps the license in force and says what to cut, andydfi license statusshows the new one waiting and why; cut reservations withydfi admin update-rpand it loads the new license within about a minute. A server started with it serves no applications until the reservations fit, while the admin plane works. See Renewing with fewer seats. - Several copies on one database each read their license file on their own, so for a minute or two after a renewal they can disagree about the seat limit and some may refuse service. We recommend renewing with a short stop: stop every copy, install the new license for all of them, then start them again.
Back it up#
Everything stateful lives in one PostgreSQL database — enrollments, device inventory, and recent challenges. Back it up exactly as you back up any Postgres (a managed snapshot schedule, or pg_dump), matched to your recovery objectives.
The server process holds no durable state, so losing a container costs nothing — it restarts clean. The database is the whole deployment. Protect it accordingly, and keep a fresh backup before any major upgrade.
Upgrading#
Upgrade with every server stopped. Stop all of them, take a backup of the database, then start the new release — the same one container you deploy everywhere. Its composition-seeder applies the release's migrations before the server starts, and a server refuses to start on a schema older than its own.
Never run servers of two releases against one database, even for a moment. A release can change how servers coordinate with each other, such as the keys of the locks they take, and a server of one release does not exclude a server of the other. A rolling replace is safe only between servers of the same release, for a configuration change or a restart.
To roll back, stop every server, restore the backup you took before the upgrade, and start the previous release. A schema the new release migrated is not guaranteed to work with the old server.