Applications: Node.js, Python and other languages

#Supported runtimes

Application types available under Software → Applications in the user panel:

When you pick the application directory, bipanel inspects the project and suggests the type, framework and commands. It checks, in this order, Gemfile, go.mod, pom.xml/build.gradle, *.csproj, package.json, requirements.txt/pyproject.toml, a standalone *.jar and index.html. Frameworks such as Next.js, Vite, Angular, Astro, Express, NestJS, Django, Flask, FastAPI, Rails and Sinatra are recognised, and you can edit every suggested command before saving.

#The administrator installs versions

The server administrator installs Node.js versions under Server Admin → Software → Node.js Versions, and Python, Go, Java, Ruby and .NET versions under Server Admin → Software → Language Runtimes. Every download is verified against the checksum published by its vendor; a file without a checksum is never installed. Users pick one of the installed versions for their application, or leave it empty to use the server default. If a language is not installed at all, applications of that type cannot be created and the panel says so. Ruby is built from source, so it cannot be installed from the panel in a container install whose image has no compiler.

For an account's own Perl modules, Ruby gems and Python virtual environments, the user panel has Software → Perl, Ruby & Python Packages.

#Creating and deploying an application

A new application has these fields:

• Name: lowercase letters, digits and hyphens, up to 40 characters.
• Directory: a path inside the home directory (default apps/<name>); it cannot be the home directory itself.
• Install, build and start commands: the start command is a single line and is required for every type except static. Static apps set a build output directory instead (default dist).
• Environment variables: up to 200. PORT, HOME, USER, PATH and a few names starting with BIPANEL_ are set by the panel and cannot be overridden.
• Domains: the domains and subdomains to attach; alias domains cannot be attached, choose their parent domain instead.

Each application gets a free port in the 10000–19999 range on 127.0.0.1, passed in the PORT variable. Your app should listen only on that address and port; the suggested commands already do. The number of applications per account comes from the package's application limit.

#Deploying from Git

Code can come from a repository cloned under Files → Git Version Control. When a repository is linked to an application, every deployment first updates the repository and then runs the install and build commands. With automatic deployment on, the provider's webhook is accepted after its signature is verified and a push starts a deployment. An optional deploy script can also be set on the repository; it runs as the account user.

If the administrator registers provider apps for GitHub, GitLab, Bitbucket and Gitea under Server Admin → Software → Git Integrations, users can connect their provider account and pick a repository from a list. The deploy key and webhook are then created on the provider automatically and both are removed when the repository is deleted.

#Zero-downtime deploys, releases and rollback

The default strategy is zero-downtime:

1. The source is copied into a new release directory and the install and build run there; the live release is untouched.
2. The new release starts in the idle slot on its own port and must pass the health check. If it fails, the new process is stopped and the live release keeps serving.
3. The web server is switched to the new port and the old process is stopped after a short drain period (10 s by default).

The last 3 releases are kept by default (configurable from 1 to 30), and you can roll back to any of them without rebuilding. Directories and files that must survive between releases (uploads, .env and so on) are defined as shared paths. With the in-place strategy the commands run directly in the application directory and rollback is not available.

#Process supervision and logs

The application process always runs under the account user's identity and is controlled with the Start, Stop, Restart and Deploy buttons.

Standard output and standard error go to a log file specific to the account and application. The panel shows the last 10 to 5000 lines (300 by default) and can clear the log. Each deployment also has its own log in the deployment history. When an account is suspended its applications are stopped, and enabled ones start again when the suspension is lifted.

#Health checks

The default check is TCP (a port connection). You can switch to an HTTP check with a path and an expected status range (default 200-399), or turn checks off. The default interval is 30 s with a 5 s timeout. An instance that fails 3 checks in a row is restarted automatically; repeated restarts back off progressively and status changes are sent as notifications.

#Applications behind the web server

The attached domain's Apache virtual host reverse-proxies to 127.0.0.1:<port>. WebSocket connections pass through, the Let's Encrypt validation path is not forwarded to the app, and a 503 maintenance page is shown when the app does not respond. Servers running the Nginx front end or OpenLiteSpeed generate their configuration from the same data. SSL certificates are issued for the domain just like for regular websites. See Web server and caching for details.

Static apps run no process; the build output directory is served directly as the document root.

#Pro features

• Replicas and load balancing: an application runs as several instances on separate ports and the Apache load balancer spreads traffic across them (by request count or by busyness, with optional sticky sessions). Rolling restarts live here too. The "Application replicas" feature must be enabled in the package; the server-wide replica limit defaults to 4.
• Preview environments: Software → Preview Environments in the user panel. For a pull request or branch, a separate copy runs on its own subdomain in the form pr-<number>.<domain>, with its own port and environment variables, optionally with an empty database or a copy of production. The address is posted to the provider as a commit status and comment, and the environment is removed when the request is closed. The repository's deploy script is not run for previews.

See Pricing for edition differences.

#What users and administrators can do

To install ready-made applications in one click see App catalog; for applications running from Docker images see Containers; for how application processes are kept apart between accounts see Account isolation.