▲ | Show HN: Snapser Starter Tier – modular back end with isolated K8s "own cluster"(snapser.com) | |
2 points by aapte 8 hours ago | 1 comments | ||
Hi HN — I’m AJ, Co-founder of Snapser. We built a modular backend for apps/games with an “own cluster” feel (strong isolation), implemented on Kubernetes namespaces under the hood. Today we’re launching our free Starter Tier. Highlights: • 33 “Snaps” (Auth, Storage, Leaderboards, Analytics, A/B Tests, etc.) • Bring your own containerized services (any language) • Your own isolated environment (namespaces + bin-packing + auto-scaling) • Starter Tier: 1 dev cluster, 2 admin seats, 5 Snaps free, no credit card What we learned: isolation over giant shared control planes; smart multi-tenancy to keep dev affordable; backends are more than tables; we baked enterprise ops defaults into day-one settings. Full article: https://snapser.com/resources/posts/starter-tier Signup (no CC): https://snapser.com/register Happy to go deep on the architecture or trade-offs. Feedback welcome! — AJ | ||
▲ | aapte 8 hours ago | parent [-] | |
Snapser Starter Tier — FAQ (architecture, isolation, limits, pricing) What is a “Snap”? A Snap is a production-ready backend module (e.g., Auth, Storage, Leaderboards, Inventory, Analytics, A/B Tests, Chat, Rewards). Each Snap bundles API surface + infra wiring (queues, schedulers, storage, observability) with sane defaults and documented extension points. Do I really get my “own cluster”? You get an isolated project environment—your own control surface, config, —implemented on Kubernetes namespaces and your own data plane, under the hood. We spread compute across nodes (bin-packing, autoscaling, idle/sleep) but keep strong boundaries (RBAC, network policies, resource quotas). Not true single-tenant hardware; also not “one big shared app.” Why not one multi-tenant control plane like other BaaS platforms? Teams want clear blast-radius and config + data isolation, plus a place to run custom services. The “own cluster” abstraction gives that mental model without dev-time costs exploding. Cold starts / idle footprint? We keep dev costs down with namespacing, aggressive bin-packing, autoscaling, and idle/sleep policies for low-traffic services. Design goal: fast enough for iterative dev, tiny when idle. What languages can I use for custom services? Anything you can containerize (HTTP/gRPC/). We handle routing, auth context, SDK generation, rollout/rollback. How is networking and auth handled? Every cluster is secure by default. Authentication and authorization are enforced via three auth types: user, API key, and internal. a) User auth: from your client apps to your backend. b) API key auth: from trusted servers or CI/CD. c) Internal auth: service-to-service and your custom code. Data portability / lock-in? a) APIs: All data is accessible via documented APIs b) Migration: You can move Snap state or replace a Snap with a custom service if needed. What’s included in the free Starter Tier? a) 1 development cluster (isolated environment) b) 2 admin seats c) 5 Snaps free (choose from ~30; beyond 5 is per-Snap pricing) d) All “Core” Snaps e) Access to Cortex (AI backend assistant, alpha) f) Community support via Discord g) No credit card required. What does “5 Snaps free” mean exactly? Add up to five Snaps to your cluster at no cost during development (e.g., Auth + Storage + Inventory + Analytics + A/B Tests). Need more? Add individually with per-Snap pricing. Prod vs dev—what’s the upgrade path? Start free on Starter. When you’re ready for production, move to Standard, which starts at $99/month. Standard tier gives you more snaps and 3 clusters so that you can move to a “Development-Staging-Production” pipeline. Upgrading is one click—no rewrites just to “go live.” Observability & ops? Every backend ships with custom infra monitors, Grafana-style dashboards, live Kubernetes log streaming, structured logs/metrics/traces, heatmaps, health checks, and rollout/rollback. No black boxes—transparent by design. How do you keep Starter affordable? We don’t allocate per-project single-tenant hardware in dev. We use Kubernetes namespaces plus proprietary scheduling/idle tech to keep footprints small and wake quickly when you’re actively building. Roadmap highlights (feedback welcome) a) More live-ops/multiplayer Snaps b) Deeper data export tools c) Richer policy/permissions editor & org templates d) More examples for popular stacks Want numbers or more detail? Ask below—happy to share more details. |