Deployment
Same platform, same console, same agent. The only question is who operates the control plane.
Cloud
We run the control plane. You install agents and register what you want protected.
- Nothing to patch, upgrade or migrate — including the database underneath it
- Agents dial out, so your network accepts no inbound connection
- Recovery points land in your storage bucket, in your region
- Schema migrations and version upgrades are handled before you notice them
This is the right choice if backups are something you need to be reliable rather than something you want to operate.
Self-hosted
The whole platform inside your perimeter.
The control plane installs as a single Go binary with a systemd unit, or runs as containers if that suits you better. It runs its own unprivileged service user, and its schema and migrations are applied on start — PostgreSQL is an ordinary distribution package and can live on the same host. Configuration lives in one environment file that survives re-installs; runtime state and certificates live in predictable, service-owned directories. The installer is idempotent, so upgrading is re-running it.
- Your PKI issues both the server and agent certificates
- No egress requirement — air-gapped estates are a supported configuration, not a workaround. Licensing is offline, so nothing has to reach us to keep running
- The same operator console, served from your own domain
- You choose when to upgrade
This is the right choice when the data cannot leave, or when the compliance conversation is shorter if it never does.
What it runs on
| Control plane | Linux (amd64), systemd or Docker, on PostgreSQL |
| Agents | Linux, macOS (arm64/amd64), Windows (amd64) |
| Protects | PostgreSQL, MongoDB and ScyllaDB; Linux and Windows servers; Cisco, Juniper, Palo Alto, Fortinet and NGINX; AWS accounts and Azure subscriptions |
| Automation | Ansible, Terraform and Python runbook steps, run on your own agents |
| Storage | Amazon S3 or MinIO, Azure Blob, Google Cloud Storage, SFTP, NFS, local disk |
| Observability | Prometheus metrics, distributed tracing, unauthenticated health probe |
| Licensing | Offline — a signed file, verified against keys in the binary |
Splitting it across hosts
The control plane runs in modes — api, grpc and worker — set per host, so the component serving the console need not be the component scheduling the work. Roles register themselves with service discovery individually, and a node running a subset answers 404 for what it does not run rather than an empty 200 the console would render as "you have nothing configured".
One caveat worth stating rather than discovering: notification delivery follows whichever process runs the automation services, so a split deployment should keep triggers and webhooks with the worker. A single-process deployment — the default — has no such consideration.
Moving between them
The agent, the policies and the archive format do not change between deployments. Starting on the hosted service and moving in-house later — or the reverse — is a migration of the control plane, not a re-implementation of your protection.
Getting started
Mail contact@daydev.org with roughly what you run and how much of it you would have to explain after an outage. We will show you the console against a realistic estate rather than a demo that only contains healthy assets.