App Servers
An app server is a program you supply: Node, Python, Go, anything that speaks HTTP. You point the panel at an executable in your home directory; the panel gives it a private address, starts it when a request arrives, stops it when idle, collects its logs, and reverse-proxies to it. Hosting architectures describes the model as a whole.
An app server is the same feature: on demand, stopped when idle, supervised by the panel. The one difference is that your program is a normal HTTP server listening on a port the panel gives it, not a module the web server loads. That's what makes it language-independent.
Your program must listen on the address and port the panel gives it, in the
environment variables IP and PORT. Everything else follows from that.
App servers, mounts, and containers need persistent services, which your provider turns on per account. If these pages refuse with such a message, ask your provider.
Write the program
The app server's page lists the same requirements:
| Requirement | Why |
|---|---|
| Speak HTTP. | The proxy forwards plain HTTP and terminates TLS for you. |
Bind to $IP:$PORT exactly. | Not 0.0.0.0, not 127.0.0.1. On any other address the proxy can't reach your app, even though it appears to run. |
| Run in the foreground. | Don't daemonize. The service manager tracks the process it started. |
Be executable (chmod +x), with a correct interpreter line. | Use the exact binary paths from Runtimes & Tools to pin a language version. |
A minimal example in Python:
#!/usr/bin/env python3
import http.server, os
addr = (os.environ["IP"], int(os.environ["PORT"]))
class Handler(http.server.BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header("Content-Type", "text/plain")
self.end_headers()
self.wfile.write(b"Hello from my app server\n")
http.server.HTTPServer(addr, Handler).serve_forever()
Example Scripts on the App Servers page has the same example in other languages.
Create an app server
The form has three fields:
- Description, to identify the app server
- Application Path, the script or executable, relative to your home directory
- Note, optional
The panel assigns the private IP address and port and shows them on the app server's page. Only your own account can reach them.
The process runs as your own user, with your home directory as its working directory, so it can read your files and reach your databases like any other process of yours.
To give the app a public URL, mount it on one of your websites, from the Website Mounts section of its page or from Mounts. One app server can be mounted on several websites and paths.
Lifecycle: on demand, not always on
There are no start and stop buttons. The panel listens on the app server's address permanently; your program starts at the first request and stops after 10 minutes without traffic. The next request starts it again, after a short delay.
Three things follow:
- Your app doesn't run between requests. That's normal, not a failure.
- After a quiet period, the first visitor waits for your app to start. Keep the start fast: a slow-starting framework makes every first page load slow.
- If the program exits with an error, the next request starts it again. But a program that fails during startup fails every request.
Test runs your app once, in a controlled way: it stops any running instance, starts the program, sends a request, and shows the response and the program's output on one screen. Normal on-demand operation resumes afterwards.
Logs
Logs streams the program's output live. The most recent lines load first, then the view follows the program. Everything your app writes to standard output or standard error lands here; there's no log file to set up.
Delete an app server
Deleting an app server also removes every website mount attached to it. The URL paths go back to whatever else serves them, usually the website's document root.
The program file in your home directory is left alone.