Platform concepts

This page collects the vocabulary used across the console, the CLI, the API, and the rest of the documentation. Read it before creating your first project: most configuration and billing decisions depend on these concepts.

Account, organization, and permissions

Account

An account identifies a person. It has a verified email, a password, and optional two-factor authentication. GitHub and Forgejo connections, used to deploy from repositories, belong to the organization and are managed by the owner in Account (GitHub section and Git provider connections). See Account settings.

Organization

The organization is where projects, billing, credit, members, and API keys live. The same account can belong to several organizations and switch between them in the console. Every project belongs to exactly one organization. See Organizations.

Roles and permissions

Each member gets a role (owner, assistant, or member) and, when needed, granular permissions per resource, such as a specific project, databases, or billing. The same permission model applies to people and API keys. See Granular permissions.

Organization API key

Key used by the API, the CLI, the GitHub Action, and automations. MCP does not use an API key: it connects through OAuth in the browser, with read-only access. It belongs to the organization, receives only the scopes you grant, and can be revoked at any time. See API keys.

Projects

Project

A project is the unit you create, configure, monitor, and pay for. Each project has a type, a plan, a payment model, and a unique ID used by the CLI and the API.

Project types

HTTP project source

An HTTP project is deployed from one of these source types, chosen at creation:

• Git repository (GitHub or Forgejo): Zenifra builds your code (Node.js, Python, or Bun) from a branch. See Deploy via GitHub and Deploy via Forgejo.
• OCI image: you provide a ready image from a public or private registry. See Deploy via OCI image.

For projects with a Git repository, you can change the repository, branch, and build settings after creation; see Git connections and sources.

Template

A template describes a ready application (image, port, variables, and optionally a database) that can be deployed in a few clicks. See Templates.

Preview environment

A temporary copy of an HTTP project created for a pull request or a preview key. It inherits the main project configuration and plan, always runs with one instance, without auto-scaling, and expires automatically. See Preview environments.

Capacity and runtime

Plan

The plan defines CPU, memory, included storage, and extra features such as a custom subdomain, metrics, health checks, auto-scaling, and IP access control. Application logs are available on every plan. The console always shows the plan features before you confirm.

Instance

An instance is a running copy of your application or database. HTTP projects can run a fixed number of instances, limited by the plan's available capacity, or scale automatically with auto-scaling. More instances increase capacity and availability, and also cost.

Exposure

HTTP projects are either public (they get a *.clients.zenifra.com address and accept custom domains) or private (no public route, ideal for workers and automations). See Network access.

Environment variables and storage

Environment variables keep configuration and secrets out of your code. Persistent storage keeps files across restarts and new versions.

Billing

Payment model

Each project is billed hourly, monthly, or yearly; scheduled Jobs are billed per minute of execution. Hourly billing gives more flexibility to change plan and storage; monthly and yearly billing reserve capacity for the contracted period. See Payment models.

Credit

Credit is the organization's prepaid balance, also used for AI consumption. See Managing payments.

Next steps

• Deploy your first Node.js application
• Console guide: create an HTTP project
• Production checklist
• Frequently asked questions