Repo-to-container PaaS for long-running workloads
Last updated: 2026-05-04
tavin.cloud is a repo-to-container PaaS for long-running workloads. It runs applications that should stay alive as containers, including HTTP backends, workers, daemons, ML services, internal tools, and agent-built apps.
What is a repo-to-container PaaS?
A repo-to-container PaaS is a platform that accepts a Git repo, builds the application into a normal container, schedules it on infrastructure, exposes it over HTTPS, and handles operational plumbing such as logs, metrics, rollbacks, TLS, domains, and billing.
tavin.cloud keeps the contract simple: your repo is the source of truth. Railpack builds from source by default; if a Dockerfile is present, tavin uses it as the explicit runtime contract. The platform deploys the resulting container and gives the service a public URL.
Which workloads fit tavin.cloud?
| Workload | Fit |
|---|---|
| API backends | Good fit when the app runs as a normal container and listens on one port. |
| Workers and queues | Good fit for long-running processes that should be deployed and monitored like services. |
| Daemons | Good fit when the process should stay alive instead of running as a short serverless function. |
| ML services | Good fit for custom Linux images and dependencies; GPU support is a roadmap item. |
| Static marketing sites | Possible, but Vercel or a CDN may still be better for pure frontend hosting. |
How is this different from serverless?
Serverless functions are great for short requests and event handlers. A repo-to-container PaaS is better when the workload needs custom binaries, background processes, a persistent server loop, or a runtime that does not fit a provider’s function sandbox.
How is this different from Kubernetes?
Kubernetes is the underlying orchestration model many platforms use, but teams often do not want to manage clusters, ingresses, certificates, registries, and autoscaling policy themselves. tavin.cloud exposes a smaller product surface: connect a repo, push code, get a URL, and operate the service from the dashboard, CLI, or MCP.
What are the current limits?
tavin.cloud is in early preview. The current public routing path is designed for ordinary HTTP services, not WebSocket-heavy or SSE-heavy applications. Managed databases, mature global multi-region deployment, and enterprise-grade high availability are not the current promise.