Current Limits

Gonvex is beta software. The current runtime executes arbitrary registered app functions from uploaded Go bundles and includes the major local/self-hosted product surfaces. The remaining limits are primarily migration safety, durable operations, fleet management, and managed hosting.

Implemented Today

The current codebase includes:

• app-local Go queries, mutations, actions, HTTP handlers, internal mutations, LiveGrid functions, and sync collections;
• uploaded source bundles compiled and cached per project;
• generated TypeScript API references and scoped schema metadata;
• safe Postgres schema sync for project and tenant databases;
• realtime queries with declared dependency filtering, serialized/coalesced reruns, shared runners, revisions, unchanged suppression, and adaptive list patches;
• durable sync collections with Postgres cursors and normalized IndexedDB storage;
• multi-project and database-per-tenant routing;
• native Google OAuth, memberships, invitations, roles, account controls, and live WebSocket session revocation;
• browser query caching and lightweight error reporting;
• recurring, per-tenant, and one-shot scheduled work;
• optional S3-compatible files and uploaded CSV/XLS/XLSX analysis;
• dashboard inspection for projects, tenants, schemas, functions, data, files, errors, logs, metrics, realtime connections, and scheduling.

Current CLI Boundary

The npm CLI currently implements:

npm create gonvex@latest my-app
npx gonvex init
npx gonvex login
npx gonvex project create my-app
npx gonvex token create "Developer CLI"
npx gonvex auth add google --origin http://localhost:5173
npx gonvex auth doctor
npx gonvex auth tenants list
npx gonvex dev
npx gonvex env list
npx gonvex env push .env.production

Top-level tenant, deploy, generate, and general runtime doctor remain roadmap commands. Tenant/membership operations live under gonvex auth, and project authentication has its own implemented auth doctor. See the CLI Reference for current authentication and project-provisioning flags.

Multi-Project Operations Are Early

The runtime and dashboard have project registry endpoints, rotatable project keys, account personal access tokens, project environment variables, per-project manifests, and database routing. There is no generally available hosted control plane.

Needed work:

• deployment records and immutable release artifacts
• dashboard UI for personal-token lifecycle and more granular custom roles
• automated zero-downtime upgrade and rollback workflows

Multi-Tenant Auth and Routing

Users can belong to multiple tenants with owner, admin, member, or viewer roles; each membership may carry additional JSON permissions. The central registry verifies membership before tenant routing, and runtime-created tenants receive separate PostgreSQL databases. Native auth supports personal-workspace and invite-only signup, tenant switching, invitation claiming, account disable/delete, and session revocation after membership changes.

Remaining operational work is mostly fleet-level:

• backup/restore orchestration across many tenant databases
• staged schema rollouts and backfills
• tenant move/export workflows
• custom named-role editing and audit export in the dashboard
• quota, billing, and organization policy

Realtime Invalidation

The runtime implements declared table/column dependencies, a tenant/table reverse index, serialized/coalesced runners, result revisions, unchanged suppression, adaptive keyed-list patches, safe shared subscriptions, and supervised active- tenant PostgreSQL listeners.

Current live-query limits:

• dependencies are explicit declarations; arbitrary raw SQL is not automatically traced
• permission-level sharing is opt-in because user-dependent handlers cannot safely share
• nested arbitrary JSON uses full replacements rather than patches
• live queries recover a PostgreSQL NOTIFY gap with a fresh snapshot rather than replaying every intermediate event

Durable sync collections add a transactional Postgres change log and resume cursor for declared single-table collections. Their v1 limits are equality filters, null/non-null exclusions, bounded eager/progressive collections, and handler-defined authorization. They do not support joins, aggregates, search, or offline mutation queues. The public Go API includes RetainFor, but the npm CLI does not yet emit custom retention into the uploaded manifest; the effective retention is currently the seven-day runtime default.

Schema Migrations Are Early

Schema sync applies safe, data-preserving changes and rejects changes that would break existing rows. Runtime startup persists schema state, batches catalog inspection, bounds tenant rollout concurrency, and skips unchanged trigger/index work.

Production migrations need:

• migration versioning
• previews
• explicit destructive-change confirmation
• rollback strategy
• per-tenant rollout control
• large-table backfill strategy

Auth and Identity Boundaries

Dashboard sessions, account personal access tokens, project memberships, and scoped project/token permissions are implemented. Native brokered Google OAuth is implemented for single-database and multi-tenant app projects with Authorization Code + PKCE, server-side Google ID-token validation, exact callback allowlists, short-lived access tokens, rotating refresh-token families, tenant memberships, invitations, role/permission propagation, account lifecycle controls, and live WebSocket revocation. Additional providers, device authorization, enterprise organization policy, recovery flows, audit export, and hosted-control-plane hardening are still incomplete.

The runtime does not yet provide additional social providers, enterprise SSO, SCIM, recovery flows, organization policy, or complete audit export. Do not expose dashboard/data-browser management endpoints as application APIs.

Storage and Data Files

File storage is optional. The runtime supports upload targets, signed/proxied downloads, metadata, deletion, direct storage, project buckets, and S3-compatible providers. The local MinIO service is a development example.

Production operators still need bucket lifecycle policy, off-host backup, malware/content scanning when their product requires it, and tested restore procedures. Uploaded data-file analysis currently supports CSV, XLSX, and XLS through runtime-managed DuckDB artifacts; it is not a general warehouse.

Scheduler Durability

One-shot jobs and deterministic cron occurrences are persisted in Postgres and claimed with renewable multi-replica leases. They survive runtime restarts and health-first rolling replacements. Registered cron definitions are reconstructed from the app bundle after startup or manifest sync.

Interrupted executions are recoverable after their lease is released or expires. Normal function errors are terminal and recorded in runtime metrics; public cancellation, manual retry, retention controls, and dead-letter APIs are not implemented yet.

Production Guidance

Treat Gonvex as beta and plan explicitly for:

• production migrations
• deployment/versioning and rollback
• tenant fleet backup/restore
• scheduler retention and dead-letter policies beyond the built-in durable queue
• identity-provider and audit requirements beyond native Google auth
• operating the self-hosted runtime, because no public managed service is available