How to run Node.js, Go, Rust or any binary on shared hosting

Introduction

A worker process is any command the panel keeps running inside your site’s container, and it does not have to be PHP. Node.js has its own type with a version picker, and the Custom type runs whatever you ship, including compiled Go and Rust binaries. Worker processes are available on every plan. A worker’s HTTP proxy serves the website’s main domain only, not its addon domains.

Node.js

For a full walkthrough with databases, settings, and GitHub deploys, see how to deploy a Node.js app.

Open the site, then Advanced and Worker processes, click Launch, and choose Node.js:

• Version. Any release from 0.12 to the current major. Choose a numbered long term support release such as 24.x rather than stable, which installed a pre-release build when we tested it. The version is installed for this site on first start, which takes a minute, and is reused after that.
• Startup command. node server.js, npm start, or whatever your application uses.
• Working directory. The folder that holds package.json.
• HTTP proxy. Turn this on and enter the port your application listens on. Leave the path empty to serve the application on the whole domain, or set a path such as api to mount it at https://yourdomain.com/api. Turn websocket upgrade on if the application uses websockets.

Your application must listen on 0.0.0.0, not localhost, so the proxy can reach it from outside the process. The proxy strips the path prefix before forwarding, so an application mounted at /api receives requests at /.

The worker does not install dependencies, so run npm install over SSH or in a GitHub deploy build script before the first launch.

Go and Rust

The container has no Go or Rust compiler, so you should build the binary elsewhere for the server’s platform, which is Linux on x86_64.

For Go, run the following command on any machine:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/server .

For Rust, build with the x86_64-unknown-linux-musl target, or build with GitHub Actions and download the release in your build script. Static binaries are recommended, because a dynamically linked binary must find its libraries inside the container.

Commit the binary or download it in the build script. Then launch a Custom worker with the command ./bin/server, the working directory that contains it, and the HTTP proxy set to the port it listens on. The log shows the binary’s own output.

We tested both while writing this guide: a Go HTTP server committed to a repository and deployed from GitHub, and a Rust file server downloaded as a prebuilt release in the build script. Each was reachable on its own path on the test domain.

Python and Other Runtimes

Python 3.12 is installed, so python3 app.py works as a Custom worker. Install packages into a virtual environment over SSH first, then use the environment’s interpreter in the command, for example .venv/bin/python app.py.

Anything else that runs on Linux and listens on a port follows the same pattern. If you can run it from a terminal, it can run as a worker.

Worker Requirements

Keep the following in mind when configuring workers:

• The working directory is required. A worker with an empty working directory never starts.
• Commands may only contain single quotes. The command runs inside a shell wrapper that breaks on a double quote. Put anything complex in a script file and make the command ./run.sh.
• The log only keeps the latest attempt. A worker that crashes at startup restarts every few seconds and clears its log each time, so the error does not appear in the panel. Run the command over SSH from the same directory to see it.
• Every change restarts every worker on the site. Adding or editing a worker briefly restarts the others.
• Deploys do not restart workers. End the build script with a line that stops the application, such as pkill -u "$(id -u)" -x node || true for Node, and the panel starts it again on the new release within a few seconds. Alternatively, press Restart container on the site overview after the deploy.

Worker Access and Limits

The worker runs as your site’s own user, inside its container, with the same resource limits as the site. It may read and write anything in your site’s home directory, and it cannot see other sites on the server.

The worker reaches your site’s MySQL through the socket at /run/mysqld/mysqld.sock. Nothing listens on 127.0.0.1:3306, so set the driver’s socket path rather than a host and port. Redis is available on 127.0.0.1:6379 on every Laravel Hosting and Node.js Hosting plan, and on Business and Cloud Enterprise for Linux and WordPress.