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.
Web terminal
You can access the Web terminal from Applications > app name > Web terminal. You can switch between your web process, background worker, or cron job using the dropdown menu.
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 MyKinsta 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. |
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.