Full-Stack & Monorepos

A frontend and its API are one app: one Telbase URL, one sign-in, and one app on your plan. Each part runs where it suits it, and the API answers under the app's URL at its own path. Your coding agent registers and deploys each part, following the Telbase skills.

One app, several services

Project structure

my-project/
├── frontend/          # Vite → Vercel       (shop.telbase.ai)
│   ├── package.json
│   └── vite.config.ts
└── api/               # FastAPI → Cloud Run (shop.telbase.ai/api)
    ├── requirements.txt
    └── main.py

The agent registers the app with the service that serves its pages, then adds the API from its own folder:

bash

cd frontend && telbase apps create shop --provider vercel --framework vite --database postgres
cd api && telbase apps create shop --service api --provider cloudrun --path /api

How requests are routed

shop.telbase.ai/api and everything under it go to the API, with the full path: /api/orders arrives as /api/orders, so the API serves its routes under /api.
Every other path goes to the frontend.
The frontend calls the API relatively (fetch('/api/orders')): there is no API URL to set and no CORS to configure, and when you turn on sign-in it covers both.
Your custom domains and your organization's domains route the same way. On an organization domain in path mode (acme.com/shop/), the whole app, its API included, sits under that base path.

Pick a free path

The frontend's own routes under the API's path are hidden: a Next.js app with its own /api routes gives its separate API another path, such as /backend.

Environment Variables

Each service has its own environment variables, held by its provider. --service picks one; without it, the app's own:

Per-service environment variables

telbase env set --project shop --service api SECRET_KEY=...
telbase env set --project shop PUBLIC_SITE_NAME=Shop

The app's database belongs to all its services. Logs, deploys, rollbacks, restarts and scaling take --service too, and the dashboard shows each service inside the app's page.

Build-time values

Values baked in at build time (NEXT_PUBLIC_*, VITE_*, PUBLIC_*) must exist before the build; changing one needs a redeploy.

Common Patterns

Frontend	Backend	Notes
Vite + React	FastAPI	Routes under `APIRouter(prefix="/api")`; proxy `/api` in `vite.config.ts` for local development
Next.js	Express	`app.use('/backend', router)`, at a path Next.js does not use
SvelteKit	Go	Go runs on Cloud Run, built without a Dockerfile
Vite + React	Docker (Java)	Docker needs a paid plan
Astro	Django	Trust the Telbase URL in `CSRF_TRUSTED_ORIGINS` and `ALLOWED_HOSTS`

On your plan

An app counts as one app whatever its services. A website that gets a service running a server counts as an app, as one that ships server functions does. Each service's deploy counts as a deploy.

Workspace monorepos

A workspace monorepo (shared packages, one lockfile at the root) deploys to Vercel from the repo root, with the app's folder given at registration:

bash

telbase apps create web --provider vercel --framework nextjs --root-directory apps/web

To Cloud Run it deploys with a Dockerfile at the root, so the build sees the workspace and the lockfile.

Universal deployment via Docker

Any language works via Docker — Java, Ruby, Rust, PHP, C#, Elixir. A project with its own Dockerfile runs on Google Cloud Run. See Docker Containers.

Workers and schedules

Cloud Run services scale to zero, so an in-process scheduler or queue consumer runs only while requests keep an instance alive. Periodic work becomes a scheduled job. A queue consumer that must keep running is not hosted: the agent deploys what runs on requests and tells you what will not run.

Next Steps

Supported Frameworks — where each kind of app runs
Docker Containers — deploy any language with a Dockerfile
Databases — PostgreSQL and SQLite
CLI Reference — every command