Space Cloud

Open-source serverless backend, honestly reviewed. The most important fact is in the first sentence of the README.

TL;DR

• What it is: A Kubernetes-based serverless platform that auto-generates GraphQL and REST APIs on top of any database — pitched as “open source Firebase + Heroku” for self-hosted backend development [README].
• Who it’s for: It was aimed at developers who wanted to skip writing backend CRUD code and get instant APIs on Postgres, MySQL, MongoDB, or SQL Server on Kubernetes [README][website].
• Current status: In maintenance mode. The project’s own README opens with: “SpaceCloud is currently in maintenance mode. Checkout Hasura or Wundergraph instead.” [README] This is not a soft deprecation notice — it’s the maintainers telling you to use something else.
• Cost: $0 for the software (Apache-2.0 license). You run it on your own Kubernetes cluster.
• Key strength: The feature set it had — instant GraphQL on any database, service mesh, event triggers, fine-grained RBAC — was genuinely interesting when it shipped.
• Key weakness: The project is no longer actively developed. The website copyright reads 2021. The Discord community listed 300+ members, which is a number that signals early-stage, not thriving. The maintainers themselves redirect you to competitors.

---

What is Space Cloud

Space Cloud was a Kubernetes-native serverless platform that tried to do what Firebase does for Google’s cloud, but on your own infrastructure on any database. The pitch from the GitHub README: “Open source Firebase + Heroku to develop, scale and secure serverless apps on Kubernetes.” [README]

The core idea was straightforward: connect it to your Postgres, MySQL, MongoDB, or SQL Server database, and it instantly exposes that database over GraphQL and REST APIs, with security rules you define rather than application code you write. You could do cross-database joins in GraphQL, stream realtime updates, trigger webhooks on database events, and control access with JWT-integrated RBAC — all without writing a backend [README][website].

It also had a DevOps angle: one-click microservice deployment, Istio-based service mesh integration, auto-scaling to zero. The pitch was that a single platform could replace your backend code, your API gateway, and your service mesh configuration [website].

The project sits at 3,996 GitHub stars with an Apache-2.0 license [merged profile]. That star count puts it in the “real project with real users” tier, but nowhere near the adoption of Hasura (30K+ stars) or competitors like Supabase (75K+ stars). The website last updated its copyright to 2021, and the README now reads as a eulogy [README][website].

---

Why people choose it — and why the question no longer applies

There are no substantive third-party reviews of Space Cloud available in the sources provided for this article. That absence is itself informative: a project this far into maintenance mode doesn’t accumulate new editorial coverage.

What we can reconstruct from the README and website is the original value proposition that attracted its ~4,000 GitHub stargazers:

Versus writing a backend from scratch. The appeal of Space Cloud was eliminating the CRUD boilerplate entirely. If your app is mostly reading and writing to a database with some business logic on top, Space Cloud would give you those APIs immediately, with security rules handled declaratively rather than baked into application code [README]. This is the same bet Firebase makes — that most apps are database + auth + storage + functions, and you shouldn’t write that infrastructure repeatedly.

Versus managed Firebase. Firebase lock-in was the pitch. Your data lives in Google’s infrastructure; you can’t move it cheaply. Space Cloud ran on Kubernetes on your own servers, on databases you control [README]. For a team burned by Firebase pricing or frustrated by Firestore’s query limitations, a Postgres-backed alternative with the same DX was genuinely appealing.

Versus Hasura (its closest competitor). Hasura auto-generates GraphQL on Postgres and is the tool Space Cloud’s own maintainers now recommend. Hasura is still actively developed, has a large community, and offers both cloud and self-hosted editions. Space Cloud attempted to add the service mesh and deployment orchestration layer that Hasura doesn’t address, which was an ambitious scope [README][website].

The honest assessment: Space Cloud spotted a real problem (auto-generated APIs on self-hosted databases) and built a credible early solution. It didn’t get the traction to sustain a team, went into maintenance mode, and now points users toward better-resourced alternatives.

---

Features

These were the capabilities at the time of last active development. Feature availability today is uncertain given maintenance status [README][website]:

Database layer:

• Auto-generated GraphQL and REST APIs on any connected database [README]
• Flexible queries, transactions, aggregations, and cross-database joins [README]
• Realtime subscriptions — live queries that push updates to clients [README]
• Supported: MongoDB, PostgreSQL (and compatible: CockroachDB, Yugabyte), MySQL (and compatible: TiDB, MariaDB), SQL Server [README]

Security:

• Fine-grained RBAC with dynamic access control rules [README][merged profile]
• JWT integration with external auth providers (Auth0, Firebase Auth mentioned in docs) [README]
• Single ingress point for all traffic; authorization at the HTTP layer [website]
• mTLS-based service-to-service policies via Istio [website]

File storage:

• Upload/download to Amazon S3, Google Cloud Storage, or local storage [README][merged profile]

Events and extensibility:

• Event triggers: webhooks or serverless functions on database or file storage events [README][merged profile]
• GraphQL wrapper for calling REST services as if they were GraphQL fields [website]

Deployment:

• Docker and Kubernetes deployment [merged profile]
• One-click microservice deployment in any language [website]
• Istio service mesh integration [website]
• Auto-scaling, including scale to zero for idle services [website]
• JavaScript SDK for frontend consumption of the APIs [README]

What’s missing or unclear:

• SSO, audit logs, team management — not mentioned in available documentation
• The Swagger/REST API spec listed in the README pointed to a v0.15.0 swagger spec, suggesting the API surface was still versioned at a pre-1.0 milestone when development slowed [README]

---

Pricing: SaaS vs self-hosted math

Space Cloud has no SaaS offering. There is no cloud-hosted tier, no managed service, no pay-per-use plan. It is software you run on your own infrastructure [README][website].

License cost: $0. Apache-2.0, meaning you can use it commercially, modify it, and distribute it without restriction [merged profile].

Infrastructure cost: You need a Kubernetes cluster. That’s the non-trivial part. A minimal single-node Kubernetes setup on Hetzner or DigitalOcean starts around $6–12/month. A production-ready cluster with multiple nodes, a managed load balancer, and persistent storage runs $30–80+/month depending on workload.

Comparison to the tools it aimed to replace:

Service	Cost at startup scale	Lock-in
Firebase (Blaze plan)	~$25–100/mo as you scale	Google cloud, Firestore format
Supabase (Pro)	$25/mo	Postgres + Supabase-specific extensions
Hasura Cloud	Free tier + $99/mo Pro	Hasura-specific metadata layer
Space Cloud self-hosted	~$15–50/mo for K8s infra	None (Apache-2.0, standard databases)

The cost case for Space Cloud was real when it was active: zero license cost, standard databases, no vendor control. The problem is that the maintenance-mode status introduces a different kind of cost — the risk that a bug you hit won’t get fixed, that a new database version breaks compatibility, or that you’re debugging a tool the maintainers have stopped maintaining.

---

Deployment reality check

Space Cloud requires Kubernetes. That is a meaningful prerequisite that immediately narrows the audience. Docker Compose is not listed as a primary deployment path [README][website]. The installation guides link to Docker and Kubernetes paths specifically [README].

What you actually need:

• A working Kubernetes cluster (EKS, GKE, DigitalOcean Kubernetes, k3s, etc.)
• kubectl access and at least basic Kubernetes literacy
• A database (MongoDB, Postgres, MySQL, or SQL Server) accessible from the cluster
• An understanding of Kubernetes ingress if you want external access
• Istio, if you want the service mesh features [website]

What can go sideways:

The maintenance-mode status is the central deployment risk. Active projects fix compatibility issues with new Kubernetes releases. Maintained projects update their Docker images for security patches. Space Cloud is not that project anymore.

The website says the last meaningful activity was circa 2021 based on the copyright date and the tone of the community links [website]. A Discord server with “300+ members” is a quiet channel, not a support community. If you hit a deployment issue, your options are the GitHub issues (which may or may not see maintainer attention) and the documentation (which may reference outdated Kubernetes APIs) [README].

Realistic time estimate for a technical engineer: 2–4 hours to a running instance if you’re comfortable with Kubernetes. Realistic recommendation: don’t do it. The maintainers themselves, inside the README you’d use to install it, tell you to go to Hasura instead [README].

---

Pros and cons

Pros

• Apache-2.0 license. Fully permissive. No usage restrictions, no “fair-code” carve-outs, no commercial licensing conversation needed [merged profile].
• No per-request pricing. Unlike Firebase or Hasura Cloud, you’re paying flat infrastructure costs with no metered API call charges [website].
• Standard databases. Your data stays in Postgres, MySQL, or MongoDB — formats you can move between tools without vendor-specific migrations [README].
• Broad database support. Covering four database families including CockroachDB, Yugabyte, TiDB, and MariaDB compatibility is a wider surface than many competitors [README].
• Kubernetes-native design. For teams already running K8s, the service mesh and auto-scaling features fit naturally into existing infrastructure [website].
• Genuinely ambitious feature set. Cross-database GraphQL joins, realtime subscriptions, event-driven webhooks, RBAC, file storage, service mesh — the scope was real [README].

Cons

• In maintenance mode. This is not a soft warning. The maintainers wrote it into the top of the README in bold, redirecting users to Hasura and Wundergraph. New features are not coming. Security patches may not come [README].
• Requires Kubernetes. There is no “just run it on a $6 VPS” path. Kubernetes literacy and infrastructure are prerequisites [README][website].
• No active community. 300+ Discord members is sparse for a project of any scale. No Stack Overflow presence, no recent blog posts, no third-party tutorials from the past two years [website].
• Pre-1.0 when activity slowed. The Swagger spec references v0.15.0. The API surface was not declared stable before maintenance mode set in [README].
• No SaaS escape hatch. If you hit a wall self-hosting, there is nowhere to migrate to within the Space Cloud ecosystem. You’re fully on your own [website].
• No managed cloud tier. Unlike Hasura, Supabase, or Appwrite, there is no cloud-hosted version to trial before committing to self-hosted deployment [website].
• Documentation may be outdated. Kubernetes APIs evolve. A project last updated in 2021 may reference deprecated APIs or image versions [README][website].

---

Who should use this / who shouldn’t

There are almost no circumstances where you should choose Space Cloud in 2026.

The maintainers have made this case explicitly. In the first lines of the README they wrote: “SpaceCloud is currently in maintenance mode. Checkout Hasura or Wundergraph instead.” [README] That’s an unusually direct concession from a project team, and it deserves to be taken at face value.

Skip Space Cloud if:

• You’re a non-technical founder looking for something you can actually get support for. Space Cloud has no active support channel that’s going to respond to you.
• You’re an engineering team building anything you’ll maintain for more than six months. Betting your backend on a project in maintenance mode is a liability that compounds over time.
• You want Kubernetes simplicity — those words don’t belong in the same sentence, and Space Cloud doesn’t resolve that tension.
• You need SSO, SAML, SCIM, or audit logs. Not documented as available.

The one narrow exception: You’re a developer who wants to study how a Kubernetes-native API gateway with RBAC and realtime subscriptions can be architected, and you’re reading the source code, not running it in production. The Apache-2.0 codebase is a legitimate reference for this.

---

Alternatives worth considering

The Space Cloud README names these directly [README]:

Hasura — the obvious replacement. Hasura does the same thing (instant GraphQL on Postgres) and is actively developed with a large community, a cloud-hosted tier for trials, and an enterprise track. It has 30K+ GitHub stars versus Space Cloud’s ~4K. If Space Cloud’s pitch appealed to you, Hasura is the project that survived and grew. Start here.

Wundergraph — the other name in the Space Cloud README. Wundergraph is a “BFF” (backend for frontend) framework that federates GraphQL APIs and is aimed at developer teams who need API composition across services. More complex than Hasura for simple use cases; more powerful for multi-service architectures.

Supabase — if you want the Firebase alternative for non-Kubernetes environments. Postgres-backed, open source (mostly), Docker Compose deployable, with a generous free cloud tier and a growing self-hosted community. This is what most non-technical founders actually end up using when they want to escape Firebase.

Appwrite — another Firebase alternative targeting non-technical users, with an easier self-hosted path (Docker Compose), built-in auth, storage, and functions. Less database-query-focused than Space Cloud was, but actively maintained.

PocketBase — single binary, SQLite-backed, instant REST API with auth and file storage. If your use case is a small app with simple data models, PocketBase is faster to deploy and maintain than any Kubernetes-based solution.

PostgREST — the stripped-down version of the same idea. Instant REST API on Postgres, no Kubernetes required, 25K+ GitHub stars, actively maintained. If you just want REST on Postgres without the surrounding platform, PostgREST is mature and stable.

---

Bottom line

Space Cloud was a real attempt to build the self-hosted Firebase — instant GraphQL and REST APIs on any database, running on your own Kubernetes cluster, with security rules instead of backend code. The feature set was credible. The architectural ambition (API gateway + service mesh + event triggers + RBAC in one platform) was genuinely differentiated. But the project didn’t gain enough traction to sustain continued development, and the maintainers have done the honest thing: they’ve put it in maintenance mode and told you where to go instead.

That honesty is worth respecting. It’s also the only recommendation you need: if Space Cloud looked interesting to you, open a tab for Hasura. It does the same core thing — instant GraphQL on Postgres — with an active team, a real community, a cloud trial tier, and documentation that was written in the last six months. If you want something simpler that runs without Kubernetes, look at Supabase or PocketBase. Space Cloud’s code will stay on GitHub under its Apache license, and the ideas it explored are worth studying. Just don’t build your startup’s backend on a project whose own maintainers have moved on.

---

Sources

Primary sources (Space Cloud):

• GitHub Repository and README: https://github.com/spacecloud-io/space-cloud (3,996 stars, Apache-2.0 license) — README maintenance notice, feature list, database support, deployment guides
• Official website: https://space-cloud.io — homepage feature overview, community links, documentation structure
• Swagger API spec: https://app.swaggerhub.com/apis/YourTechBud/space-cloud/0.15.0 — REST API surface reference (referenced in README)

Referenced in article for context:

1. Paperblog (Clouding VPS Review) — en.paperblog.com — not a Space Cloud review; provided as source [1] in input materials
2. EricMelillo.com (Cloudways Review 2026) — ericmelillo.com — not a Space Cloud review; provided as source [2] in input materials
3. DevTeam.Space — Cloud Integration Best Practices — devteam.space — general cloud integration context
4. Techie-Show.com — Cloud WordPress Install Tutorial — techie-show.com — not a Space Cloud review; provided as source [4] in input materials
5. DigitalOcean — How To Use Cloud-Config For Your Initial Server Setup — digitalocean.com — general cloud-config context

Note: No substantive third-party reviews of Space Cloud were available in the provided source materials. All Space Cloud-specific claims above are drawn from the project’s own README and website.