Envora

Inspiration

Sales and QA teams waste time building one-off demo databases or reusing stale data. We wanted a way to describe a scenario in plain English and get a live, isolated environment in minutes—no engineering tickets, no manual SQL.

What it does

Envora spins up sandboxed demo environments on demand. You pick a project (e.g. demo CRM), write a scenario prompt ("CRM with $26M pipeline and 8 organizations"), and launch. The platform:

Creates a dedicated Postgres database for that sandbox
Uses Claude to generate realistic, scenario-matched seed data (INSERTs)
Seeds the DB (with AI-powered retry if the SQL fails)
Starts a Docker container running your demo app against that DB
Gives you a URL to a running instance with the right data

Sales get fresh, on-brand demos; QA get repeatable, realistic data. Describe the scenario → get a live sandbox.

How we built it

Platform backend: Express (Node/TypeScript), Prisma (SQLite) for projects, scenarios, and sandbox metadata; Postgres (one DB per sandbox) for sandbox data.
AI layer: Anthropic SDK — we send schema + scenario prompt to Claude; it returns SQL INSERTs. On seed failure we send the Postgres error back and retry (up to 3x).
Orchestration: provision.ts runs the 7-step pipeline (create DB → apply schema → generate data → seed → launch container → wait for ready → mark running).
Containers: Docker + dockerode to run the demo app image with a sandbox-specific DATABASE_URL.
Frontend: Next.js 14 (App Router), React, Blueprint.js; shared types in platform/shared/types.ts for type-safe API usage.
Demo app: Standalone demo-crm (Next.js, Prisma, Postgres) as the first "project" we support.

Challenges we ran into

Seed failures not failing the sandbox: Provisioning continued to "launch container" even when seeding failed. We now check seedResult.success and throw so the sandbox is marked failed with the real error.
Admin DB mismatch: Reset/delete used a hardcoded Postgres URL; if sandbox Postgres was on another port, we targeted the wrong server. We now derive the admin URL from the same SANDBOX_POSTGRES_* env vars as provisioning.

Accomplishments that we're proud of

End-to-end flow: From "create scenario + launch" to a running demo app with AI-generated data in one pipeline.
AI + DB correctness: Prompting Claude for dependency-ordered INSERTs and using seed-with-retry so bad SQL gets fixed by the model instead of manual debugging.
Pipeline-value targeting: Supporting prompts like "$26M pipeline" and instructing the model to use a scratchpad so generated deal amounts sum to the target.
Clean separation: Platform DB (SQLite) vs one Postgres DB per sandbox; shared TypeScript types; single orchestration module for the 7 steps.

What we learned

Fire-and-forget + polling: Returning 201 immediately and updating sandbox status in the DB lets the UI poll for "running" or "failed" without blocking the API.
Model quirks: Small prompt details (trailing "...", wording like "26mil") change behavior; normalizing and being explicit in the system prompt matters.
One source of truth: Keeping API shapes in shared/types.ts and using them in both frontend and backend avoids drift and speeds up iteration.

What's next for Envora

Shareable links: Public or time-limited URLs so prospects can open a sandbox without logging into the platform.
Auth and quotas: Per-user or per-team limits on active sandboxes and usage.
More demo apps: Support additional project types (e.g. other schemas and Docker images) beyond the demo CRM.