Skip to content
Engineering

Deployments

Real deploys across a growing set of real providers.

Overview

The Infrastructure Runtime deploys through a provider-agnostic connector interface — Vercel, Netlify, Railway, Google Cloud Run, AWS Elastic Beanstalk and EC2, Docker/VPS, DigitalOcean, Linode, Vultr, Hetzner, Oracle Cloud, Azure (VM and App Service), Kubernetes, Render, Fly.io, GitHub Pages, and Hostinger — each shelling to that provider's own already-authenticated CLI or API, never inventing a deployment mechanism a provider doesn't actually have.

How it works

  1. 1

    Request a deploy

    "Deploy this to production," or let Paw suggest the right target for the project.

  2. 2

    Safety gate

    Production-impacting deploys go through an approval gate before running.

  3. 3

    Deploy and verify

    Paw deploys, then checks real health signals rather than assuming success.

  4. 4

    Roll back if needed

    A failed health check can trigger an automatic rollback to the last good deployment.

Use cases

  • • Shipping a side project without learning every provider's own CLI
  • • Standardizing deploy workflows across a team using different providers

Limitations

  • • Every provider requires its own already-authenticated CLI/API session on your machine — PawOS never manages your cloud credentials for you
  • • Providers with no real staging/rollback concept (like a single Fly.io or Render app) honestly report that limitation instead of faking one