Introduction
ZopDay is ZopDev's deployment platform.
ZopDay is ZopDev’s deployment platform. It provisions the infrastructure, deploys your services onto it, and operates the running estate, on your own AWS, GCP or Azure account. Run it as managed SaaS or, on the Enterprise plan, self-host it on your own cloud.
It is a control plane, not a proxy. Your workloads run on your cloud, and ZopDay acts on it only with the access you grant, logging every change in its audit trail. Workloads run as standard Helm releases on your clusters. If you leave, the workloads stay where they are.
Infrastructure, List view; every cluster, VM, and datastore across your connected clouds in one table, with its connections, cost, and status.
Provision, deploy, operate
ZopDay owns the three stages before the bill arrives, then hands the running estate to ZopNight: everything ZopDay provisions flows into ZopNight’s cost reports and recommendations without a second connection.
Provision
Day zero. One Provision drawer stands up the network, the cluster and the datastores under it, with provider parity across AWS, GCP and Azure. Retries resume from the last successful step, and ZopDay never mutates a customer-managed database.
Networking
VPC, subnets, NAT and DNS zones on Route 53, Cloud DNS or Azure DNS, with VPC peering on AWS and GCP.
Kubernetes clusters
EKS, GKE and AKS with control plane, workers, cluster IAM and a Helm baseline, typically ready 15 to 30 minutes after you create one.
Managed datastores
PostgreSQL and MySQL on RDS, Cloud SQL or Azure Database; Redis on ElastiCache, Memorystore or Azure Cache.
VM pools
A multi-service VM environment in a private subnet with NAT egress: fixed pools, or an Auto Scaling Group on AWS and a Managed Instance Group on GCP.
In-cluster components
A Helm component catalogue of platform components (such as the NGINX ingress controller and cert-manager) installed onto the registered cluster, and upgraded the same way.
Adopt what you already run
Register a cluster you already operate, or adopt a running PostgreSQL, MySQL or Redis. ZopDay never owns its lifecycle.
Deploy
Every day. Connect a repo, and ZopDay detects the framework and the port, builds the image on an isolated runner, rolls it out and routes a live URL. You don’t need a Dockerfile, and you get one-click rollback. Environment variable values are treated as secrets and never shown back, and datastore passwords go to your cloud-native secret manager (AWS Secrets Manager, Google Secret Manager, Azure Key Vault), never ours.
The pipeline
Resolve, clone, detect, build, deploy, watch the rollout. Each stage writes an append-only event; a failure retries up to three times, then stops in a dead-letter state.
Two substrates
The same pipeline ships to a cluster through Helm, or to a Linux VM as a container behind Caddy with automatic HTTPS.
Builds on GitHub Actions
A dispatched workflow builds the image and pushes it to your registry. Builds never run inside your cluster.
Rollback
A rollback creates a new revision that re-ships the earlier image rather than rewriting history, so the timeline stays intact.
Hosts and domains
Bind a custom domain to a service, and the DNS record and the route are kept in step on attach and detach.
Connecting services
Pass one service’s address to another, and attach a database with its connection variables set for you.
Operate
Every minute. Once it is running, ZopDay is where you read the live state, change it inside guardrails, and account for what changed. It is also where the lifecycle levers live: scale a VM pool’s idle containers to zero, resize a VM’s machine type and boot disk in place without re-provisioning, and copy a database between Cloud SQL instances.
Live manifests
Read any Kubernetes object as YAML, edit it behind a server-side dry run, and apply. Dangerous kinds are blocked and Secret values are stripped for non-admins.
Infrastructure board
Clusters, VM pools and datastores together, their links reconciled against live cluster state and marked Live, Drift or Unverified.
Chart upgrades
ZopDay compares an installed app’s live chart version against the newest published and offers the upgrade, with a values diff before you confirm.
Access and audit
Every mutating request is logged with the user, the resource and the outcome, and the feed can be forwarded to your SIEM.
Live Kubernetes state across every connected cluster is on 21 resource pages with detail drawers. ZopDay keeps each registered cluster’s status in step with what it discovers on your account, so an inactive cluster shows a clear gate instead of a cryptic SDK error.
What you can spin up
Beyond your own repositories and images, ZopDay installs ready-made applications from the App Catalog: today Superset, Outline, WordPress, JupyterHub, LiteLLM, LocalAI and HolmesGPT. The App Catalog is served live, so it grows without a ZopDay release.
Starter Templates
Pick an app and a cluster and ZopDay builds the whole chain: project, provisioning job, namespace, environment, deployment and its first revision. Kubernetes only.
App Catalog installs
An installed app is configured through the values its own chart publishes. ZopDay owns the release, so deleting the service uninstalls it.
Shareable install link
One link carries a visitor to a running service from a chart, a Git repo or a container image. Every value is validated, and secrets never travel in the link.
ZopCloud
A managed pool ZopDev operates, with no cloud account needed. Pick a repo, deploy, and the service is live on a real URL; point the next deploy at your own cloud when you are ready.
Security and trust posture
ZopDay connects to your cloud accounts through the provider’s own trust mechanism: a keyless assume-role on AWS, Google OAuth on GCP, and a service principal or federated identity on Azure. From there it holds no standing credentials on your infrastructure. Each deploy gets a short-lived kubeconfig, VM commands run over the cloud’s own IAM-gated exec channel with port 22 closed, and every build callback is signed.
- BYOC: when you deploy to your own AWS, GCP, or Azure account, your workloads run there and we never host them. ZopCloud Quick Deploy is the exception by design: it runs your service on a VM pool ZopDev operates.
- Cloud-native secrets: datastore passwords land in your cloud’s secret manager, and ZopDay keeps only the reference.
- Control plane, not a proxy: on your own cloud, your application traffic never passes through ZopDay.
- Audit trail: every mutating request is logged with the user and the outcome, in an append-only trail you can forward to your SIEM.
- ISO 27001:2022 and SOC 2 Type II: independently audited.
- Data residency: you choose the cloud region your workloads and datastores run in; compliance certifications for that region are the cloud provider’s.
- Built on GoFr (Apache 2.0): open source, with no proprietary runtime.
Who uses ZopDay
McAfee runs platform engineering on ZopDay in production, across multiple AWS accounts and Kubernetes clusters. Every cluster uses the same wizard, hardening defaults, and audit trail.
Next steps
Quickstart
Sign in, connect a cloud account, register a cluster, and ship your first deploy.
Pipelines
How the deploy pipeline works, from trigger to live URL.
Rollbacks
How a rollback re-ships an earlier revision, and what it does and doesn’t revert.
Cluster provisioning
Provision EKS, GKE, or AKS end to end from the Provision drawer.