Monster Manual: Supabase

Stat Block

Dimension	Score	Rating
Structural difficulty	14/14	Impractical (maximum)
Compliance/maintenance	10/13	Very High
Confidence	High
Estimated packaging effort	100+ hours
Ongoing maintenance	Unsustainable

Repository: github.com/supabase/supabase Language: TypeScript/Go/Elixir/Haskell (multi-language platform) License: Apache-2.0 Stars: 80,000+ | Release frequency: monthly compose releases

The Verdict

Supabase is not an application. It is a platform: a complete backend-as-a-service stack consisting of 10-15 independent services written in five different languages. The docker-compose.yml is over 400 lines and defines PostgreSQL, GoTrue (auth), PostgREST (Haskell REST API), Realtime (Elixir WebSocket), Storage API (Node.js), Kong (API gateway), Studio (Next.js admin), Supavisor (Elixir pooler), Edge Functions (Deno), Logflare (Elixir logs), Vector (Rust log pipeline), imgproxy (Go), and pg_meta (Node.js).

The structural score of 14/14 is the theoretical maximum. Every axis is at or near its ceiling. This is not merely difficult to package; it is architecturally incompatible with Cloudron’s single-container model.

Structural Analysis

A1. Processes (3): At minimum 8-10 separate processes required. Each is a separate Docker image built from a separate repository in a different language.

A2. Data storage (0): PostgreSQL is the core (Cloudron addon). However, it requires multiple custom roles (6+ database users), custom schemas, and PostgreSQL extensions (pgvector, pgjwt, pg_graphql, pgsodium, supautils) that the Cloudron addon likely does not support.

A3. Runtime (2): Five different language runtimes: Go, Haskell, Elixir/Erlang, Node.js, and Deno. Plus Kong requires OpenResty/Lua. Only Node.js is in cloudron/base.

A4. Message broker (0): No external broker. Inter-service communication via HTTP/WebSocket. Realtime listens to PostgreSQL WAL directly.

A5. Filesystem writes (2): Extensive across every service. Kong config alone requires runtime template expansion.

A6. Authentication (3): GoTrue manages API auth. Studio uses separate HTTP Basic Auth. Two entirely different auth systems, neither compatible with Cloudron. JWT validation is baked into every service.

Compliance Analysis

B1. SSO quality (3): GoTrue is identical to the AppFlowy blocker. Every service validates GoTrue JWTs. Replacing it would require forking every service.

B2. Upstream stability (2): VC-funded, rapid development. Monthly compose releases with frequent breaking changes. Service versions change constantly. Compatibility not guaranteed when mixing versions.

B3. Backup complexity (2): File Storage data is not in the database. Analytics uses its own schema. Edge Function code is on the filesystem. Custom roles and extensions must be preserved across restore.

B4. Platform fit (1): All traffic goes through Kong on a single HTTP port. The API gateway pattern actually works with Cloudron’s proxy. But internal routing complexity is high.

B5. Config drift (2): Over 50 environment variables. Kong YAML templates expanded at boot. Edge Functions deployed as files. Studio allows runtime config.

Why Every Strategy Fails

“Cram everything into one container.” A 4+ GB image, 4+ GB RAM, 10+ processes in 5 languages. Any single process failure breaks the platform.

“Package only essential services.” The minimum set (GoTrue, PostgREST, Realtime, Kong, Studio, pg_meta) is still 6 services in 4 languages.

“Use Cloudron’s PostgreSQL addon.” It lacks the required extensions and custom role hierarchy.

“Wait for a single-binary.” No indication Supabase plans this. The microservice architecture is fundamental.

Community Consensus

No one has attempted packaging. Every technical comment on the forum reaches the same conclusion. Key quotes:

• timconsidine: “definitely in the non-trivial category. For myself, Parse is as good as Supabase for 80-90% of needs, and is easier to package.”
• umnz: “It would be hard to combine the one-click app approach of Cloudron and managing the complexity of Supabase.”

Alternatives for Cloudron

• Parse Server (community package): covers 80-90% of use cases, simpler architecture
• Directus (in app store): REST/GraphQL from any SQL database, OIDC support
• Baserow (in app store): open source Airtable alternative with API
• PostgREST alone (could be a lightweight package): the auto-generated REST API, which is the core of Supabase’s data layer
• Pocketbase (worth assessing): single Go binary, SQLite, auth built in

Recommendation

Do not attempt. This is the most complex application assessed and the most clearly impractical. The structural score of 14/14 is the maximum possible. If Supabase is a hard requirement, run it on its own VPS with docker-compose or use the hosted service. Cloudron is the wrong platform for this workload.