Environments

An environment is a running instance of your code with its own URL, containers, and configuration.

Isolated URLs

Each environment gets a unique URL like pr-42.example.com

Auto Lifecycle

PR environments are created, updated, and removed automatically

Deployment History

Track every deployment with status, duration, and full output logs

Container Logs

Stream runtime logs of any service from your terminal with nebioncli logs

PR Environments

When you create or update a pull request, Nebion automatically creates a PR environment:

• Named pr-{number} (e.g., pr-42)
• Accessible at https://pr-{number}.{your-domain} (e.g., https://pr-42.example.com)
• Redeployed when you push new commits to the PR
• Automatically removed when the PR is merged or closed

Manual Environments

Create manual environments for long-lived deployments like staging, QA, or demo instances.

1. Open your project page and click Add environment
2. Fill in the details:

Field	Description
Title	A name for the environment (e.g., staging, qa, demo)
Branch	The Git branch to deploy (e.g., develop, main)
Domain	The custom domain (e.g., staging.example.com)

3. Click Save, then click Deploy to trigger the first deployment

Manual environments persist until you explicitly delete them.

You can also set a Recipe when creating the environment to override the project's recipe — see Per-environment recipe.

Auto-deploy on push

By default, manual environments require clicking Deploy to update them. You can enable automatic redeployment on every push to the tracked branch:

1. Open the environment and go to the Settings tab
2. Enable the Auto-deploy on push checkbox
3. Click Save

Now any push to the environment's branch will trigger a redeployment automatically — the same way PR environments work. Tag pushes and branch deletions are ignored.

Prerequisite

A webhook must be configured for the project. Without it, Nebion has no way to receive push events from your Git provider.

Protected environments

Enable Protected (no auto-deploy) to prevent push and webhook events from ever triggering an automatic deployment of an environment. A protected environment can only be deployed by clicking the Deploy button.

1. When creating the environment — or later on its Configure tab — enable the Protected (no auto-deploy) checkbox
2. Click Save

Use this to guard critical environments — such as production — from being redeployed by an accidental push.

While an environment is protected:

• Only its owner — the user who created it — can deploy, edit or delete it, or change its variables and settings; everyone else can only view it
• Its title, server and domain are locked — remove protection first, save, then edit
• Reset environment (deploy from scratch) is unavailable in the Deploy dialog

Protected wins over auto-deploy

Protected takes priority over Auto-deploy on push. If both are enabled, the environment is never auto-deployed — protection always wins. Manual deployments via the Deploy button are unaffected.

Per-environment recipe

A project's recipe (docker or manual) controls how every environment is deployed. By default each environment inherits the project's recipe, but you can override it per environment when you create it:

1. When creating the environment, choose a Recipe (Docker or Manual)
2. Leave it empty to inherit the project's recipe (the default — nothing changes for existing environments)
3. Click Save

This lets a single project and repository run environments on different recipes — for example, docker for short-lived preview environments and manual for a production environment deployed with your own commands.

To support this, a single .nebion.yml may declare both a Docker section (docker-compose-yaml / services) and a manual section (tasks.deploy / tasks.destroy) at the same time. Each recipe reads only the keys it needs: the Docker recipe ignores tasks.deploy / tasks.destroy, and the manual recipe ignores docker-compose-yaml. See Project Configuration and Manual Deployments for the keys each recipe uses.

Recipe is set at creation

Like the project recipe, an environment's recipe is fixed when the environment is created and cannot be changed afterward — the form locks the field and a change is rejected on save. To switch an environment's recipe, delete it and create a new one.

Quick Access

Use nebioncli hub for an interactive terminal dashboard to browse all your projects and environments, view logs, and SSH into containers.

Environment Page

Each environment has the following tabs (Configure is available for manual environments only):

OverviewConfigureSettingsVariablesActions

Overview

Shows environment details and deployment controls:

• Sidebar — Type, status, PR number (or identifier), branch, server, last updated, environment URL
• Deploy button — Triggers a new deployment with the latest code. Check Reset environment to deploy from scratch (not available for protected environments). While a deployment is already queued or running, Deploy and Delete Environment are disabled and unlock automatically when it finishes.
• Deployment history — Table of all deployments with build ID, date, status, duration, and View Output button
• How to connect via CLI — Shows the nebioncli ssh command for this environment
• Delete Environment — Removes all containers and data

Configure

Manual environments only. Edit the environment's Title, Domain, Branch and Server, and toggle Protected (no auto-deploy) — while it is on, the title, server and domain are locked.

The recipe is chosen when the environment is created and cannot be changed here.

Settings

Protect the environment with HTTP Basic Auth (username and password) and, for manual environments, toggle Auto-deploy on push. New environments start with the project's Basic Auth settings, if any; changes here apply to this environment only and take effect on the next deployment.

Sticky pins the environment to the top of the project's environment list and is available for every environment, PR environments included. The list shows sticky environments first, then manual environments, then PR environments — newest first within each group.

Variables

Manage environment variables. See Environment Variables for details.

Actions

Run on-demand commands against the environment -- clear caches, export databases, check status, and more. Actions are defined in your .nebion.yml and become available after deployment. See Actions for details.

Container logs

Container logs are not shown in the web interface. Use nebioncli logs (add -f to follow) or the logs view in nebioncli hub.

Deployment Status

Status	Meaning
SUCCESS	Deployment completed successfully
RUNNING	Deployment is in progress
WAITING	Deployment is queued
ERROR	Deployment failed - click View Output for details
STOPPED	Deployment was manually stopped

Viewing Deployment Output

Click View Output on any deployment to see the full log. This shows:

• Repository cloning progress
• Container startup
• Pre-rollout and post-rollout task results
• Error messages if the deployment failed

Tip: When a deployment fails, View Output is the best place to diagnose the issue. Look for the first FAILED entry.

Redeploying

Click the Deploy button on the environment overview to redeploy with the latest code from the branch. The same deployment can be started from the terminal with nebioncli deploy -p <project> -e <environment> --wait (see the CLI reference) or over the API with POST /api/environments/{id}/tasks.

One deployment at a time

Deployments of one environment run strictly one after another. While one is queued or running, the Deploy and Delete Environment buttons are disabled — hover over them to see the active deployment. They unlock automatically as soon as it finishes, no page reload needed.

Check the Reset environment (deploy from scratch) checkbox to stop all containers, remove data, and do a clean deployment. Use this when:

• Environment variables changed and a normal deploy doesn't pick them up
• Containers are in a broken state
• You want a fresh start

Deleting an Environment

PR environments are automatically deleted when the pull request is merged or closed. You can also delete them manually.

Manual environments must be deleted manually:

1. Open the environment page
2. Click Delete Environment
3. Confirm the deletion

WARNING

Deleting an environment stops all containers, removes volumes and data, and makes the URL inaccessible. Make sure you have saved any data you need.

HTTP Basic Authentication

Environments can be protected with HTTP Basic Auth so that a browser login prompt appears before the application is accessible. Enable it on the environment's Settings tab, or at project level for environments created afterwards. A change takes effect on the next deployment.

Storage

Each environment has a shared storage directory at /var/www/storage. Files uploaded through your project's file management are automatically synced to this location and available in all containers.