Web terminal
Access your application containers directly using the integrated 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.
Web terminal
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 using the second dropdown menu.
Access the application web terminal.
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:
Then run the following command:
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.