Core concepts

Four things to understand before going deep: organizations, projects, environments, and deployments. They nest like this:

Organization
└── Project
    └── Environment (production, staging, ...)
        └── Deployment (a single build of your code)

Organization

An organization holds projects, billing, and members. Each one has its own subscription, projects, and team — invite members and assign them roles. When you sign up, your first organization is created automatically. You can create or join more at any time.

You can belong to many organizations. Use the org switcher in the dashboard header to move between them.

Roles inside an organization: Owner, Admin, Member. See Roles and permissions.

Project

A project is a single deployable unit. One project = one repo (or archive) = one plan.

Each project has:

• A framework (Next.js or Nuxt)
• A plan (Dev, Launch, Grow, Scale, Enterprise)
• One or more environments
• A default source (GitHub repo or archive)

Environment

An environment is a long-lived runtime target on your project. You name them however you like — production, staging, preview, or anything else.

Each environment has:

• Its own URL (custom domain or *.velumi.dev)
• Its own environment variables
• Its own deployment history
• Its own source (or it inherits from the project's default source)
• A location (region where it runs) — coming soon

Environment status reflects whether traffic is being served — not the success of the last deployment:

A failed new build doesn't bring down a running environment; the previous deployment keeps serving until a new one succeeds.

Deployment

A deployment is one build of your code, created on each deploy trigger.

Deployment lifecycle:

You can roll back to any previous successful deployment in seconds.

How they fit together

A typical setup:

• Organization: "Acme Agency"
• Project: "Acme Marketing Site" (plan: Grow)
• Environments:
  • production → custom domain, main branch
  • staging → *.velumi.dev URL, staging branch
• Deployments: triggered manually per environment. Automatic deploys on push are coming soon.

Billing model in one paragraph

Plans are per project, not per organization. An organization can hold many projects, each on its own plan. Bandwidth is the only usage metric — there's no charge for builds, requests, function invocations, or seats. A spend cap on each paid plan limits overage charges. See Plans for tiers.