Web terminal

The application Web terminal gives you command-line access to the container your application’s web process, background worker, or cron job is running in. You can use the web terminal to run scripts and read files. This is useful for debugging issues, performance monitoring, or manually executing scripts ad hoc. To access the web terminal, you’ll need to:

Have at least one successful deployment of the application.
Have a healthy application that is running. If there are any errors or the application is stopped, the web terminal will not be available.

Logs are not available in the web terminal. Any files you create in the terminal will not be available to your application unless you have added persistent storage and the files are being created in the persistent storage volume. Any file changes made in the terminal will be lost with the next application deployment unless you have added persistent storage and you’re changing files stored in the persistent storage volume.

You can access the Web Terminal from Applications > app name > Web terminal. You can switch the shell type from the first dropdown menu and choose between sh, bash, and zsh. You can also switch between your web process, background worker, or cron job.

Nixpacks binary directories

With Nixpacks, the binary directories may differ from the default binary directories for the application language. The following table shows the binary directories used for some of the most common languages:

Language	Directory
Node.js	/nix/var/nix/profiles/default/bin/node
Ruby	/nix/var/nix/profiles/default/bin/ruby
Python	/nix/var/nix/profiles/default/bin/python
Java	/nix/var/nix/profiles/default/bin/java
Scala	Scala doesn’t have a specific default binary path like some other compiled languages. When you compile a Scala program, it generates bytecode that runs on the Java Virtual Machine (JVM). The compiled Scala classes are typically stored in a directory structure that mirrors the package structure of your code. This is similar to how Java classes are organized. By default, when you compile a Scala source file, the compiled .class files will be placed in the same directory as the source code (within a subdirectory structure based on the package declarations). If needed, you can install Scala’s runtime tools using a Dockerfile instead of using a Nixpack.
PHP	/nix/var/nix/profiles/default/bin/php
Go	Go doesn’t have a specific default binary path like some other compiled languages. When you compile a Go program, the resulting binary executable is typically placed in the same directory as your source code by default. If needed, you can install Go’s runtime tools using a Dockerfile instead of using a Nixpack.

Buildpack binary directories

When you add an application in Sevalla using Buildpacks, the binary directories may differ from the default binary directories for the application language. The following table shows the binary directories used for each buildpack language:

Language	Directory
Node.js	/layers/heroku_nodejs-engine/dist/bin/node
Ruby	/usr/bin/ruby
Python	/usr/bin/python
Java	/layers/heroku_jvm/openjdk/bin/java
Scala	Scala doesn’t have a specific default binary path like some other compiled languages. When you compile a Scala program, it generates bytecode that runs on the Java Virtual Machine (JVM). The compiled Scala classes are typically stored in a directory structure that mirrors the package structure of your code. This is similar to how Java classes are organized. By default, when you compile a Scala source file, the compiled .class files will be placed in the same directory as the source code (within a subdirectory structure based on the package declarations). If needed, you can install Scala’s runtime tools using a Dockerfile instead of a buildpack.
PHP	/workspace/.heroku/php/bin/php
Go	Go doesn’t have a specific default binary path like some other compiled languages. When you compile a Go program, the resulting binary executable is typically placed in the same directory as your source code by default. If needed, you can install Go’s runtime tools using a Dockerfile instead of a buildpack.

Django/Python commands with Nixpacks

If you’re using Nixpacks and want to run Django/Python commands within the web terminal, you must first activate the virtual environment with the following command:

. /opt/venv/bin/activate

Then run the following command:

python manage.py

Troubleshooting

When opening the web terminal, if you see an Error 1016 – Origin DNS page instead of the terminal screen, this is due to a slight delay in DNS propagation. Wait 1 minute and refresh the page until you see the terminal screen. If the issue persists beyond a few minutes, contact our Support team.
When you open the web terminal, if you see the error Connection closed with error code: 4005 or 4001, check that your application is running and you can access the application.

Hey 👋

Quick starts

Projects

Applications

Databases

Object storage

Load balancers

Static sites

Templates

Sevalla API

Billing

Company settings

Integration

User settings

Support

Service information

Web terminal

Web terminal

Nixpacks binary directories

Buildpack binary directories

Django/Python commands with Nixpacks

Troubleshooting

​Web terminal

​Nixpacks binary directories

​Buildpack binary directories

​Django/Python commands with Nixpacks

​Troubleshooting

Web terminal

Nixpacks binary directories

Buildpack binary directories

Django/Python commands with Nixpacks

Troubleshooting