Introduction

Deploro is a hosted developer platform. Connect a repo and get a live app with its own PostgreSQL database, file storage, realtime, and a custom domain. This site documents the REST API and the deploro CLI so you can drive the platform from code, scripts, or CI.

What is Deploro

Every Deploro project gets an isolated PostgreSQL database, a Cloudflare Worker or Pages deployment, R2-backed file storage, realtime WebSocket updates, outbound webhooks, and a REST API that's generated automatically from your schema (API Studio). You can manage all of this from the dashboard, the CLI, or by calling the API directly. All three drive the same platform through the same API.

Ways to use Deploro

Dashboard

Point-and-click project management, table editor, SQL console, deploy logs, and settings.

app.deploro.com

CLI

Script anything the dashboard can do (provisioning, migrations, deploys, env vars) from a terminal or CI job.

npm i -g deploro

REST API

The same Worker API that powers the dashboard and CLI. Call it directly with a personal access token.

api.deploro.com

API Studio

Every table in your project database gets its own REST API and OpenAPI 3.1 spec, generated automatically.

/api/projects/:id/studio

Base URL

All API requests go to the platform Worker:

https://api.deploro.com

Per-project end-user auth (Auth-as-a-Service: OTP, email/password, OAuth sign-in for your own app's users) is mounted at /auth/:slug/* on the same host. Inbound GitHub webhooks are delivered to /webhooks/github, also on the same host.

Authentication

The API supports two authentication modes:

Session cookie: what the dashboard uses. POST /api/auth/login sets an httpOnly deploro_session cookie (JWT, 7-day expiry). Send it with credentials: "include" on cross-origin requests.
Personal access token (PAT): what the CLI and scripts use. Create one from the dashboard or with deploro token create, then send it as a bearer token:

curl https://api.deploro.com/api/projects \
  -H "Authorization: Bearer deploro_pat_..."

A PAT is scoped to one or more projects and to a read or write capability level, set at creation time (deploro token create <name> --read --write --project my-app). It cannot manage other platform users or issue new tokens. For those, log in and use a session instead. Endpoints marked admin in the reference require an admin-role account regardless of which auth mode is used.

Legacy prefix: tokens minted before the Deploro rebrand still validate as gallium_pat_.... Both prefixes are accepted everywhere a token is read.

CLI quickstart

The fastest way to explore the API surface is through the CLI, which talks to the same endpoints documented here.

Install & log in

Install the CLI and authenticate with a personal access token from the dashboard.

Create a project

Spin up a project and provision its isolated Postgres database.

Deploy

Connect a repo for auto-deploy on push, or trigger a manual deploy.

# install
npm install -g deploro

# authenticate (paste a PAT from Dashboard → Settings → Tokens)
deploro login --token deploro_pat_...

# create a project and provision its database
deploro create my-app
deploro db create

# connect GitHub and deploy on every push
deploro github connect
deploro repo link my-org/my-app --branch main

# or trigger a deploy by hand
deploro deploy trigger
deploro deploy status

See the full CLI reference for every command, or the API reference to call the same operations directly over HTTP.

How deploys work

A deploy, whether triggered by a push to your connected branch or by deploro deploy trigger, clones the repo, installs dependencies (pnpm if a pnpm-lock.yaml is committed, otherwise npm), runs your build script if package.json declares one, and publishes the resulting directory to your project's own Cloudflare Worker.

Build output directory

Deploro infers where your build writes its output from your dependencies, then publishes that directory:

Detected	Expected output	Notes
next	out/	Requires `output: 'export'` (see below)
gatsby	public/
@sveltejs/kit	build/	Use the static adapter
anything else	dist/	Vite, Astro, CRA-style builds
no build script	repo root	Falls back to the first of `public/`, `www/`, `static/`, `dist/`, `build/`, `out/` containing an `index.html`

If the expected directory isn't there, Deploro looks for another one containing an index.html and logs the substitution. If nothing publishable is found, the deploy fails rather than shipping a directory that isn't your site. A build that produced nothing usable is an error, not a success with an empty result.

Next.js must be a static export. Deploro's build pipeline publishes static assets, so a server-rendered Next app cannot deploy as-is: next build writes .next/, and only output: 'export' produces the out/ directory Deploro publishes. Static export is mutually exclusive with Middleware, dynamic server routes, server actions, and route handlers. If your app uses any of those, set up the OpenNext Cloudflare adapter and commit its wrangler.jsonc, which switches this project onto the Worker path below. A deploy that hits this fails with a message naming both options.

Repos with a Wrangler config

If your repo has a wrangler.toml, wrangler.json, or wrangler.jsonc at its root, Deploro runs your build script and then wrangler deploy instead of publishing a static directory, so your Wrangler config decides what ships. This is the path for real server-side Workers, including SSR frameworks with a Cloudflare adapter.

When a deploy fails

deploro deploy status shows the failure reason inline; deploro deploy logs prints the full build transcript. Both read the unified timeline, so they cover Worker/Pages and VPS deployments alike.

A deploy reported as timed out is usually not a hang. Read the build log above the timeout notice: if it stops mid-step, the build process was most likely killed for running out of memory. Builds share a machine with other tenants, so an unusually heavy build (large dependency trees, bundlers configured for high parallelism) can exceed what's available.

Every project also gets a {slug}.deploro.app subdomain, attached automatically after the first successful deploy. If that URL returns a 404, the deploy published a directory with no index.html at its root. Check the build output above, not DNS.