Multi-tenant platform for restaurant brands

launch every restaurant as its own operating surface

Forkbase gives agencies and restaurant groups one control plane for tenant onboarding, reservations, catalog management, shopping workflows, role-based access, and domain-based isolation. One platform, multiple restaurants, clean separation.

Open Superadmin Preview Manager View Preview Shopper View

Domain-native Each tenant resolves by host, so every restaurant gets its own branded entrypoint.

DB-first Reservations, catalog items, contact leads, and user permissions live in PostgreSQL.

GCS-backed Image uploads now land in Google Cloud Storage instead of script-based proxies.

Live tenant control Snagom deployment

Turquaz SF Slug: turquazsf

Active

Reservations DB-backed slot capacity and cancellation tokens

Enabled

Image Storage Uploads served from Google Cloud Storage

GCS

1 platform superadmin surface

3 tenant roles: admin, manager, shopper

2 live entry modes: path and dedicated subdomain

Launch sequence Customer onboarding

1. Create tenant Restaurant name, slug, plan, target domain

2. Point DNS Customer sets A record for their panel subdomain to your server IP

3. Issue SSL and proxy host Snagom enables nginx and certificate for that hostname

What Forkbase does

One backend for many restaurant tenants

Forkbase is not just a login page. It is the operations layer for customer restaurants, with isolated data, per-tenant domains, structured roles, and workflow tooling behind one platform.

Tenant isolation by host

Each incoming domain resolves to the correct tenant from stored metadata instead of mixing brands in one surface.

Role-based daily operations

Admins manage configuration, managers run store operations, and shoppers execute item workflows with scoped access.

Reservations in the database

Availability, reservation creation, cancellation, and contact submissions now run inside your own stack.

Media on cloud storage

Catalog and order images upload to Google Cloud Storage and return stable public URLs for dashboards.

Operating workflow

From onboarding to restaurant go-live

The platform itself is live. Per-customer rollout is now an operational checklist, not a product build problem.

Create the tenant

Configure stores and roles

Set stores, enable reservations where needed, and create admin, manager, and shopper accounts.

Activate the hostname

DNS must point to your server, then nginx and TLS must be provisioned for the exact customer host.

Hand off access

Once DNS, SSL, and proxy are active, the tenant resolves automatically from the stored custom domain record.

Customer domain reality

Adding a subdomain to your IP is necessary, but not sufficient.

A tenant record such as panel.turquazsf.com is only the application mapping. The request will resolve to the right tenant only after the hostname actually reaches nginx and has a valid SSL certificate there.

Customer must create the DNS record for the panel subdomain and point it to your server IP.
Snagom must issue a certificate for that exact hostname.
Snagom must add an nginx HTTPS host mapping that proxies that host to Forkbase.
Only after those steps will the stored tenant custom domain start working directly under that URL.

Role access

Choose your workspace

When a restaurant team opens its panel domain, the first job is simple: move the right person to the right control surface without confusion.

Admin Access

Tenant admins manage stores, users, catalog items, and oversee the full order pipeline.

Manager Access

Managers create orders, review history, track repeat demand, and re-order from previous runs.

Shopper Access

Shoppers update item execution status, manage substitutions, upload receipts/images, and complete orders.

Snagom deployment notes

Shared platform https://www.snagom.com/forkbase/

Dedicated subdomain https://forkbase.snagom.com/forkbase/