Platform concepts
How projects, deployments, hostnames, and tokens map onto the apps your users build.
Three parties are involved when a platform runs on Easel:
| Party | Example | Uses |
|---|---|---|
| Easel | Builds, hosts, routes, and issues certificates | |
| You, the platform | An AI app builder | The Easel dashboard for one-time setup, then the API from your backend |
| Your users | Someone building an app with your product | Your product's UI. They never see Easel |
One project per app
Give each app your users build its own project. A project is the unit of isolation: it has its own builds, functions, environment variables, logs, and domains, so one user's app can't read another user's variables or serve on another user's hostname.
Projects live in your workspace. Create them with the API as apps appear; the
SDK's projects.ensure() creates the project the first time and returns it
after that, so you can call it on every publish.
Every publish is a deployment
Each publish creates a new, immutable deployment. Older deployments stay available, so rolling back only points production at an earlier one, with no rebuild. See Promote and roll back.
A project's functions start when a request arrives, so an app nobody visits doesn't hold a machine. Busy apps scale with their traffic. See Functions.
What your users' apps can be
Easel builds the same apps it builds for any project:
- A supported framework, such as Next.js or Vite.
- Plain HTML, CSS, and JavaScript, optionally with Vercel-style functions in an
api/directory. A file such asapi/entries.jsthat exportsGETandPOSThandlers answers/api/entries.
Your platform can add its own files at publish time, such as a badge or a
vercel.json with rewrites and headers.
Where the source comes from
Easel deploys source you send it. It doesn't need a Git repository:
- A sandbox where your product generated the app. The sandbox uploads its files to a single-use URL, or your backend streams an archive out of it.
- Your own storage, such as a database or object store. Your backend sends the files.
See Deploy source.
Hostnames
An app can answer on three kinds of hostname:
| Hostname | Example | Setup |
|---|---|---|
| Easel's generated URLs | trip-planner-acme.preview.easelusercontent.com | None. See Deployment URLs |
| A name under your wildcard domain | trip-planner.yourplatform.app | Verify your wildcard domain once; each name is then live as soon as you assign it |
| Your user's own domain | trips.example.com | Your user adds one DNS record |
Setting up the wildcard domain is a one-time job for you; see Set up your domains. Assigning names and connecting your users' domains happens per app; see Your users' domains.
Use a dedicated domain for your users' apps, separate from your own product's domain, so their apps can't read or set your cookies. See Choose a domain.
Tokens
Your backend authenticates with a workspace token, which can do anything in your workspace. From it, mint narrower tokens limited to some projects, some actions, and a short lifetime. Never put a workspace token where generated code runs. See Tokens.
What Easel doesn't run
Easel hosts your users' frontends and functions. It doesn't provide:
- Databases or object storage
- Incoming WebSockets
- Sandboxes or dev servers for generating apps
Use a separate service for each, and pass its credentials to the app as environment variables.