Skip to content

Infrastructure

One platform. Four infrastructures.

Deploy, database, auth, and domains are one product with one control plane. Here is what each of them actually does when you push.

Start building Read the docs

Deploy. Push code, get a live URL.

Point glashDB at a repository. We detect the framework, build it in an isolated container on a hardened host, route it through nginx, and hand back a system URL with SSL already on.

Deploy documentation

  • Framework auto-detect

    Next.js, Nuxt, Remix, Vite, static, Node, Express, Django, FastAPI, and Flask.

  • Container per project

    Every app builds and runs inside its own sandboxed container on the host agent.

  • Rollback to any build

    Previous images stay warm - reboot an earlier deployment from the CLI or the dashboard.

  • Build output you can read

    Streamed build logs, plus a diagnoser that explains the common failures in plain English.

Database. Postgres, wired in on day one.

Provision a Postgres database per project and glashDB injects DATABASE_URL into the runtime for you. Browse the schema, run SQL, define row-level security, and migrate in from somewhere else.

Database documentation

  • SQL runner with a safety net

    A risk classifier blocks destructive statements and warns on unbounded writes before they run.

  • Row-level security

    Define, apply, and test RLS policies against the live database from the dashboard.

  • Migrate in

    Bring data across from Supabase, Neon, MongoDB, or a plain Postgres dump.

  • Schema and data browser

    Schemas, tables, column types, and row previews without leaving the app.

Auth. Sign-in that ships with the stack.

glashAuth gives each project its own user store, session handling, and role model - so authentication is a switch you turn on rather than a service you go integrate.

Auth documentation

  • Email, OAuth, and magic link

    The sign-in methods most apps need, configured per project.

  • Passkeys and TOTP

    WebAuthn passkeys and time-based one-time codes for second-factor sign-in.

  • Roles and scoped keys

    Role-based access control, API keys scoped to a project, and revocable sessions.

  • Audit trail

    Sign-in events, session activity, and admin actions recorded per project.

Domains. DNS, SSL, and routing, handled.

Every project starts on a glashdb.com subdomain. Attach your own domain and glashDB walks the DNS records, issues the certificate, and keeps the edge route pointed at your current build.

Domains documentation

  • Custom domains

    A guided setup wizard checks each record and tells you exactly what is still missing.

  • Automatic SSL

    Certificates are issued and renewed for you - apex, subdomains, and wildcards.

  • Edge routing

    Traffic is published to the edge and re-pointed atomically when you deploy or roll back.

  • Redirects and CDN

    Path redirects, cache rules, and per-domain analytics from the same screen.

Platform

The parts you only notice when they are missing.

Isolated by default

Builds and runtimes execute in a hardened sandbox on the host agent, with the project's source confined to its own root directory.

Secrets stay encrypted

Environment variables and connection strings are encrypted at rest and injected into the container at start, never baked into an image.

One control plane

Deploy, database, auth, and domains share a single project, a single team, and a single audit log - not four dashboards stitched together.

Built to be scripted

Everything the dashboard does is an API call. The glash CLI and the MCP server drive the same endpoints your agent can.

$ glash deploySee the workflow

Four infrastructures.
One push.

Start building Launch app