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

View runtime logs from all services directly in the browser

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, 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.

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 five tabs:

OverviewSettingsVariablesActionsLogs

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.
• 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

Settings

Configure environment-specific settings (title, branch, domain for manual environments) and toggle Auto-deploy on push and Protected.

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

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.

Logs

View container runtime logs:

1. Select a Service from the dropdown (or view all)
2. Choose a Period (e.g., Last 24 hours)
3. Click Filter

Use logs to debug application errors, check web server access logs, or monitor database connections.

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.

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. Contact your administrator to configure this.

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.