Pyo
Pyo Cloud

How Pyo works

Pyo runs your services on servers you own, and handles the rest.

pyoyour serversbackupsPyo itselfon your server or Pyo Clouda deploy, step by stepHTTPSeach requestrequestsreads, writesqueriesbackupsimagecommandsstatus, logs, metricsrequest logsqueriesjobsmanageif it failsvisitorsbrowsers, apps, API clientsyour domains or free onesweb firewallchecks each request firstwhen you turn it onOWASP Core Rule SetPyo Gatewaywebsites, TCP and UDP portsdomains live without redeployfree HTTPSaccess rulesrate limitsbuildson a server or a build serverevery Git pushDockerfilezero configfilesvolumes that keep datawhen a service restartsbackupsone-click restoremove between projectsservicessites, APIs and workersreplicas across your serversautoscalingzero-downtime deploysrollbacksself-healingcron jobsdatabasesPostgres, MySQL, key-valuerestore Postgres to any momentand MySQL to its latest backupautomatic failoverpoint-in-time recoveryread replicasimportPyo agentone on each clusterconnects out to Pyonothing connects inlog collectoron each serversends request logsbackup storebuilt-in or your own S3files, encryptedPostgres and MySQL,to a point in timekey-value, encryptedPyo itself, encrypteddashboard and APIwhere you, the CLI andAI assistants workteams and rolesencrypted secretsactivity logalertsanalytics and logsobservabilityClickHouserequests and metricsfor analytics and logsregistryyour built imagesservers pull from herePyo's databasePostgresteams, projects, settingshistory, encrypted secretsbackground workersdeploys, backups, checksdashboardin your browserCLIin your terminalAPIfor your scriptsMCPfor AI assistantsyou and your teamowner, admin, developer, viewer1 pushpush to Gitor choose Deploy2 builda builder onyour servermakes an image3 storethe image goesto the registry4 startone new replicastarts besidethe old ones5 checkits health checkpasses, trafficmoves to it6 livean old replicastops, repeateduntil all are newroll backold replicas keep servingthe previous version returnsyou can turn this off
Read from top to bottom. Visitors, in browsers, apps and API clients, reach your services over HTTPS, on your own domains or free ones. Pyo wraps your servers, your backups and its own parts. On your servers, visitors arrive at Pyo Gateway, for websites and for TCP and UDP ports. It gives free HTTPS, puts domains live without a redeploy, and applies access rules and rate limits. When you turn on the web firewall, with the OWASP Core Rule Set, it checks each request for attacks first. The gateway sends requests to your services: sites, APIs and workers, with replicas across your servers. Services have autoscaling between a minimum and maximum on CPU and memory use, zero-downtime deploys, one-click and automatic rollbacks, self-healing that moves stateless services to a healthy server, and cron jobs. Services read and write files on volumes, which keep their data when a service restarts, are backed up, restore in one click and can move between projects. Services send queries to databases: Postgres, MySQL and key-value, with automatic failover to a replica on another server, point-in-time recovery that restores Postgres to any moment and MySQL to its latest backup, read replicas and import. Builds turn your code into an image on every Git push, from a Dockerfile or with zero config, on one of your servers or a build server, and send it to Pyo's registry. The Pyo agent, one on each cluster, connects out to Pyo, so nothing connects in. Pyo sends it commands, and gets back status, logs and metrics. A log collector on each server sends request logs to Pyo. Files and databases are backed up to the built-in store or your own S3 bucket: files encrypted, Postgres and MySQL to a point in time, key-value encrypted, and Pyo itself encrypted. Pyo itself runs on your server or on Pyo Cloud. Its dashboard and API are where you, the CLI and AI assistants work, with teams and roles, encrypted secrets, an activity log, alerts, and analytics and logs. It keeps teams, projects, settings, history and encrypted secrets in its own Postgres database, which also holds the jobs that background workers run: deploys, backups and checks. Requests and metrics go to ClickHouse, for analytics and logs. The registry holds your built images, and servers pull them from there. Below it all is you and your team, as owners, admins, developers and viewers, working from the dashboard, the CLI, the API or an AI assistant over MCP. Then a deploy, step by step. You push to Git or choose Deploy. A builder on your server makes an image. The image goes to the registry. One new replica starts beside the old ones. When its health check passes, traffic moves to it. An old replica stops, and this repeats until all are new. If it fails, the old replicas keep serving and the previous version comes back. You can turn this off per service.