Skip to Content
We are conducting a survey to learn how startups, SMEs, developers, and technical teams currently host, deploy, and operate software. Take the survey
Infralane
Infralane
Getting startedCore concepts

Core concepts

Infralane groups resources so that ownership, capacity, access, and billing remain understandable as your team grows.

The resource hierarchy

Workspace └── Project ├── Resource pool │ ├── Application │ └── Application └── Resource pool └── Application

Workspace

A workspace is the shared area for a company, team, or individual. It owns collaboration settings, the GitHub connection, members, and the billing wallet. When you switch workspaces, the available projects and resources change with it.

Project

A project is an organizational boundary inside a workspace. Applications and resource pools are created in the active project. Select the correct project before creating anything; otherwise you may place a resource in the wrong operational context.

Resource pool

A resource pool is a purchased allocation of CPU, memory, storage, and a selected region. Applications inside the pool share its available capacity. You pay for the pool rather than treating every application as a completely separate capacity purchase.

Plan the pool around the combined needs of its applications. An application allocation cannot be useful if the pool does not have enough capacity for all workloads that need to run at the same time.

Application

An application describes what to deploy and how it should run. Its configuration includes:

  • a Git repository or image source;
  • an application type: web service, static site, or worker;
  • build and start settings when applicable;
  • a resource pool plus CPU and memory allocation;
  • optional environment variables and persistent volumes.

An application name is permanent after creation. Other deployment settings can be changed from the application’s Settings tab.

Deployment

A deployment is one release attempt for an application. Creating an application starts its first deployment. Saving a settings section starts another one. The deployment history therefore gives you a time-ordered view of releases and their outcomes.

Common states are Pending, Live, Inactive, and Failed.

Source choices

SourceChoose it whenYou provide
Git repositoryInfralane should build your source codeRepository, branch, optional root directory, runtime, and commands
Docker imageYou already publish a runnable imageImage reference, application type, port where applicable, and resources

Public Git repository URLs can be entered directly. Repositories selected from a connected account require the Infralane GitHub App to be connected to the workspace.

Capacity and application allocation

Pool capacity and application allocation answer different questions:

  • Pool capacity: how much total CPU, memory, and storage the project has purchased in that pool.
  • Application allocation: how much CPU and memory a particular application can use from the selected pool.

Before creating or resizing production capacity, verify the estimated monthly price shown in the dashboard. Prices and available configurations can change; do not rely on old screenshots or copied examples.

Customer-facing and sensitive information

Application names, descriptions, repository names, domains, deployment status, and non-secret configuration are useful for collaboration. Passwords, tokens, private keys, registry credentials, MFA setup keys, and environment secrets are sensitive.

Only enter a secret in the field intended to hold it. Do not put secrets in a name, URL, build command, support ticket, or screenshot.

Last updated on