Dora NodaMost "AI agent" pitches from a deployment platform are a chatbot wrapped around a dashboard. Better-PaaS shipped something narrower and more interesting: three fixed permission tiers, a token an agent can hold without ever seeing your admin password, and a public GitHub repo you can read in an afternoon to check the claim. It's a small, AGPL-3.0, single-maintainer project — not a funded competitor — but it's a concrete answer to a question this list keeps circling in the abstract: what does "agent-first" actually look like when someone builds it, instead of markets it?
What Better-PaaS Actually Ships
Better-PaaS is a self-hosted control plane you install on your own Linux VPS or Mac host — a single curl command or a Docker Compose clone, a Go backend, a Next.js dashboard, 1 vCPU and 1GB RAM as the stated minimum. It builds from Git via Nixpacks (no Dockerfile required), issues zero-downtime deploys with rollbacks and health checks, terminates custom domains through Caddy with automatic Let's Encrypt certificates, and — the part that matters here — treats an AI coding agent as a credentialed caller with its own identity, not a guest borrowing your shell.
The mechanism is a three-tier permission profile, chosen when you run paas connect:
| Profile | Can do | Can't do |
|---|---|---|
| Observer | List apps, view logs | Deploy, restart, manage agents |
| Deployer | Observer + deploy, redeploy, restart | Manage other agents, view audit trail |
| Operator | Full automation (deploy, scale, env vars, domains) | Manage agent credentials, view/export audit log |
The token itself — prefixed bpagt_…, AES-256-GCM encrypted at rest, saved to disk at file mode 0600 — is scoped to that profile for its lifetime. Cursor or Claude Code never sees the admin password; if the token leaks, the blast radius is whatever that profile allows, and it's revocable without touching anything else. paas setup wires up seven MCP tools on top of that — paas_status, paas_list_apps, paas_get_app, paas_deploy, paas_redeploy, plus log retrieval — and every call an agent makes lands in an audit log with scope, timestamp, and resource attached. That's the whole pitch in one sentence: an agent that can deploy your app without being able to read the credential that could destroy it.
How That Compares to What bex Ships Today
Bex's own MCP server already treats an agent as a first-class caller — deploy, restart, get_service, and list_logs are API calls scoped to the specific App the agent is authorized against, not a shell with kubectl reach. But the authorization model underneath that surface is coarser than Better-PaaS's three tiers: a scoped API key plus an audit log, with the scoping boundary drawn at the App level rather than at the action level within an App. A key authorized against an App can deploy it, restart it, and read its logs — there's no equivalent of "this token can only ever call paas_status and never paas_deploy" without provisioning a second key by hand and remembering which one you handed to which agent.
That gap is small in absolute terms — App-scoped keys plus an audit trail is a legitimate, shippable security posture, and it's the same one most agent-operated platforms are running today. But Better-PaaS proves the next increment isn't exotic engineering: it's three enum values on a token and a permission check on each tool call. An agent that only ever needs to read logs and redeploy on a webhook has no business holding a token that can also touch environment variables or custom domains, and right now on bex that distinction lives in which key you chose to hand out, not in what the platform enforces. Better-PaaS's Observer/Deployer/Operator split is a concrete, working argument for baking that distinction into the token itself before an incident forces the question — the same lesson a run of 2026's agent-caused production incidents already made expensive for anyone still treating "the agent has a key" and "the agent has the right key" as the same statement.
The Managed-Database Bet: What Convenience Buys, and What It Doesn't
Better-PaaS bundles one-click Postgres, Redis, MySQL, MongoDB, and MariaDB, all running on the same private Docker network as the apps that use them, with a database explorer built into the dashboard and $0 platform fee beyond the VPS itself. For a solo developer standing up a side project, that's a real, honest win: no separate managed-database bill, no second vendor account, a database running five seconds after you ask for one.
It's also the exact feature bex's own roadmap deliberately stays out of — and the reason isn't ideology, it's operational honesty about what a one-click database actually is. A database that lives on the same VPS as the app that queries it shares that VPS's failure domain: if the box goes down, the app and its data go down together, and there's no failover target because there's only one node. Backups run on a cron schedule to your own S3-compatible bucket, which is real protection against data loss but not against downtime — restoring from a nightly dump after a disk failure is a different SLA than a standby replica taking over in seconds. None of that makes Better-PaaS's database feature a bad idea; it makes it a convenience feature, correctly priced at zero because the thing being sold is one-click provisioning, not the high-availability engineering that a "managed database" claim implies at enterprise scale.
Bex takes the other side of that trade on purpose: managing tenant databases is a stated non-goal, not a missing feature, on the theory that reimplementing what Patroni and pgBackRest already do well is a worse use of a platform team's time than the git-push-to-HTTPS path it actually owns. A tenant running Postgres on a bex-managed Hetzner fleet gets the same dollar-side benefit Better-PaaS offers — no managed-database line item metered on top of a box they're already paying for — and keeps the failover, backup-verification, and connection-pooling work as theirs to own, exactly as they would running Postgres directly on any VPS. Better-PaaS chose to own that work for you, on hardware that doesn't have a second node to fail over to; bex chose not to own it at all, and says so.
A Single Maintainer Beat the Funded Competitors to the Obvious Answer
What makes Better-PaaS worth writing about isn't scale — it's a project on GitHub from a single named maintainer, not a funded startup, running on hardware that costs less per month than a single Claude Code subscription. That's also exactly why it could ship a three-tier token model before better-resourced competitors did: there's no product committee weighing whether "Observer" cannibalizes an enterprise RBAC upsell, no sales team asking for the granular version to be gated behind a paid tier. The AGPL-3.0 license means the entire permission-check implementation — the part every agent-operated platform's security story actually rests on — is sitting in a public repo anyone can read line by line, not a page of marketing copy asserting the tokens are scoped without showing how.
That transparency cuts both ways. An AGPL project with one maintainer is also a bus-factor-of-one dependency: there's no company behind it if the maintainer stops, no support contract, no roadmap commitment beyond what gets merged next. A team adopting Better-PaaS today is betting on a specific person continuing to care about the project, which is a fundamentally different risk profile than adopting a platform backed by a company with revenue and a team — the same tradeoff this list has already tracked when a funded vendor goes dark or pivots (Daytona closing its production repo, Ownkube's managed-agent layer sitting on rented EKS rather than owned hardware). None of that makes the permission-tier design wrong. It makes "read the code, don't just believe the pitch" the correct response to any agent-security claim, Better-PaaS's included — which is precisely what an AGPL license lets a prospective user actually do, and what a closed competitor asking for the same trust does not.
The Part Worth Copying, and the Part Worth Refusing
Strip away the framing and there are really two separable questions Better-PaaS's launch forces onto every agent-operated PaaS building in this space: should tenant credentials be tiered by action, and should the platform manage tenant databases at all. The first is worth adopting — a Deployer-shaped token that can restart a service but not read its audit log is a small, mechanical change with no honest downside, and it closes a real gap between "app-scoped" and "action-scoped" that bex's current key model doesn't yet draw. The second is worth refusing on the evidence, not on principle: a database that's one Docker container away from the app it serves is convenient right up until the VPS it's sharing has a bad day, and a platform that's honest about not selling HA it can't back is a more trustworthy claim than one that bundles a database feature and lets the availability story go unstated.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and an MCP server that already treats an AI agent as a first-class caller. Star the repo on GitHub or deploy your first app today.
