Deploy anywhere
UserTasks splits its infrastructure into eleven areas — database, auth, storage, realtime, scheduler, email, secrets, KMS, cache, log export and directory sync — and each one has its own provider. Deploy on Supabase with nothing else to configure, then move areas to AWS, Azure, Google Cloud or your own servers one checked, reversible switch at a time.
The path every install takes
You never have to pick your final topology up front. Each area moves on its own, with the app running in between, so you can check every step before you take the next.
One project gives you the database, auth, storage, realtime and scheduling. No provider settings — every area starts on its default.
Move files to your bucket, email to your domain, secrets to your vault, sign-in to your IdP. One switch per area; the app keeps running.
Stop at hybrid, or carry on to a single cloud, several clouds, or a network with no internet at all. The database moves last.
# every area: provider and health
usertasks-admin status
# plan, then run: files to S3, email to SES
usertasks-admin switch storage --to s3 --dry-run
usertasks-admin switch storage --to s3 --yes
usertasks-admin switch email --to ses --yes
# every switch, with rollback ids
usertasks-admin historyThe same command for every area. How a switch runs
01
The default, and a complete topology in its own right: one Supabase project, Resend for email, and the app wherever you like to run Node.js.
Supabase only
People and clients
Browser · REST API · MCP · CLI
UserTasks
Web, API and worker · Any Node.js host or the Docker image
Built in
Supabase projectSupabase
Email APISaaS
02
Keep the Supabase database, and put the areas your security team cares about under your own account: files in your bucket, email from your domain, credentials in your vault, sign-in through your IdP.
Hybrid: Supabase + AWS
People and clients
Browser · REST API · MCP · CLI
UserTasks
Web, API and worker · Unchanged: wherever the app runs today
Built in
Supabase projectSupabase
AWS accountAWS
03
One cloud for everything — one IAM model, one audit trail, one region. The database moves last, after auth, realtime and the scheduler.
ECS on Fargate (web + worker), or App Runner with an EventBridge tick
Azure Container Apps (web, migrate job, tick job)
Cloud Run (service + migrate job)
04
When the services you must use already live in different places. Every area is configured on its own, so any combination works — with a few rules that keep it fast.
Multi-cloud
People and clients
Browser · REST API · MCP · CLI
UserTasks
Web, API and worker · Azure Container Apps, next to the database
Built in
Azure (primary region)Azure
Google CloudGoogle Cloud
SaaSSaaS
05
Everything inside your network, with no SaaS and no outbound internet. The reference profile runs on a network with no route out, and its smoke test proves the app can’t reach the internet.
On-premises / air-gapped
People and clients
Browser · REST API · MCP · CLI
UserTasks
Web, API and worker · Docker Compose or Kubernetes on your servers
Built in
Your network (no internet)Your network
Eleven areas, one choice each
Each area is independent within a few rules — the database moves last, SSE realtime works with any database, files off Supabase become storage:// references. Provider names are shown as text; every option below exists today.
DB_PROVIDERSupabase, or any PostgreSQL 15+ with the same row-level security.
AUTH_PROVIDERSupabase Auth, built-in passwords, or OIDC / SAML single sign-on.
STORAGE_PROVIDERSupabase Storage, local disk / NFS, S3 and MinIO, Azure Blob or Cloud Storage.
REALTIME_PROVIDERSupabase Realtime, or built-in Server-Sent Events on LISTEN/NOTIFY.
SCHEDULER_PROVIDERpg_cron in the database, the built-in worker, or any external cron.
EMAIL_PROVIDERResend, any SMTP relay, Amazon SES, Azure Communication Services, Microsoft 365 or Gmail.
SECRETS_PROVIDEREnvironment and mounted files, encrypted in Postgres, Vault / OpenBao, or your cloud’s secret store.
KMS_PROVIDEREnvelope encryption of stored credentials with a key that never leaves your KMS.
CACHE_PROVIDERRate limits and invalidations shared by every replica: memory, Postgres or Redis / Valkey.
One event stream per workspace, shipped to the log platform you already run.
Users and groups from your directory, pulled on a schedule or pushed over SCIM.
usertasks-admin switch
The target is probed before anything changes: reachable, writable, configured. A failed check stops the switch.
Settings and every row a switch touches are backed up; each step is recorded as it starts and finishes.
If a step fails, fix the cause and run the same command again. The provider setting is written last.
usertasks-admin rollback restores settings and undoes data changes where it can — URLs, accounts, pg_cron jobs, data keys.
Release gates run the standalone, on-premises, Azure and Google Cloud profiles end to end, and a full move of a seeded Supabase install onto plain PostgreSQL — sign-in with migrated passwords, files, jobs, log export and the row-level security snapshot included.
Topology changes the services around the engine, not the engine. Workflows, tasks, the API, the MCP server and the CLI behave identically on every one of them — keep the app next to its database and you keep the speed. How we measure it
No. Supabase only is a complete topology, and hybrid — Supabase for the database with some areas in your own cloud account — is the most common end state. Move an area only when you have a reason to.
Yes. Every switch takes a backup and records its steps; usertasks-admin rollback restores the settings and undoes its data changes where possible. Moving the database never writes to the source, so pointing the app back is always possible.
AWS, Microsoft Azure and Google Cloud, through their own services and identities where it matters (managed identity, IAM roles, service accounts), plus any PostgreSQL, S3-compatible store, SMTP relay, OIDC or SAML identity provider and Redis-compatible cache.
Yes. The on-premises reference profile runs on a network with no route out, and its smoke test fails if the app can reach the internet: PostgreSQL, built-in auth or Keycloak, MinIO, SSE realtime, the worker and an SMTP relay.
The decision guide maps your constraints — residency, one cloud, no internet, existing vendors — to a topology, with the switch sequence to get there from Supabase.