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 the server capacity your applications share. Connect your own Linux server for free Infralane management; its CPU, memory and storage become available to the project. You pay the hosting provider separately. Optional Infralane-hosted pools are paid resources purchased through the dashboard.

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, Docker image or ZIP source;
an application type: web service, static site, worker or TCP/UDP service;
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 source, resource or runtime settings starts another one; updating only a description does not. 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

Source	Choose it when	You provide
Git repository	Infralane should build your source code	Repository, branch, optional root directory, runtime, and commands
Docker image	You already publish a runnable image	Image reference, optional granted registry credential, application type and resources
ZIP archive	Your source or static files are on your computer	A validated ZIP, root directory and build/runtime configuration

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 server makes available to that pool.
Application allocation: how much CPU and memory a particular application can use from the selected pool.

Management of your own server is free; review hosting and resizing charges with your provider. For optional Infralane-hosted capacity, review the complete charge shown in the dashboard before creating or resizing a pool.

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.