Documentation

How to set up, manage and deploy your web applications on this here service.

Quick start

In short, your web app needs three things: a working Dockerfile, source code in a GitHub repository that spwnr can access, and it must listen on the port provided via the PORT environment variable. With those in place, and after following the steps below, your web app will be available at your-fancy-app.spwnr.io

1

Create an account

Sign up for a spwnr account here on this site.

2

Set up a project

Choose a name, pick a subdomain, and decide which servers your project will be built and hosted on.

3

Connect GitHub

Link your GitHub account so spwnr can see your repositories. You decide which repos to grant access to.

4

Deploy

Click Deploy, watch the build and deploy logs, and if everything looks good, your app is live.

Docker configuration

Docker is used to build and run your applications. Docker lets you package your app and everything it needs (runtime, libraries, system dependencies) into a single image that can be started the same way everywhere. To deploy on spwnr, your repository must include a Dockerfile that describes how to build and run your web app.

It is a good idea to have Docker installed in your own environment and make sure you can build and run your app locally before trying to deploy to spwnr. If it works locally with Docker, it will most likely run here too.

Ports & networking

TL;DR: Your app must listen on the port specified by the PORT environment variable.

When spwnr runs your Docker image, it injects environment variables and connects your container to an internal network behind a reverse proxy (Traefik). One of the most important environment variables is PORT.

Your web application must listen on the port specified by the PORT environment variable. The port you use for local development (for example 3000 for a Next.js dev server or 5173 for Vite) does not matter when deploying to spwnr.

  • PORT is set by spwnr when your container starts.
  • The reverse proxy forwards incoming requests to your container on this internal port.
  • Your application should not hard-code a production port like 3000 or 8080. Instead, it should read PORT from the environment.
  • The EXPOSE instruction in your Dockerfile is optional and does not affect anything here.
Framework-specific notes
Framework / stack Default behavior What to ensure for spwnr
Next.js Dev server runs on 3000 by default. In production, you typically use next start or the generated server.js (standalone output). Make sure your production command uses the PORT variable, for example:
CMD ["sh", "-c", "next start -p $PORT"] or use the standalone server.js which reads PORT.
Phoenix (Elixir) The recommended release configuration reads PORT in config/runtime.exs. Ensure your endpoint configuration uses System.get_env("PORT"), for example:
http: [ip: {0,0,0,0}, port: String.to_integer(System.get_env("PORT") || "4000")] .
Node.js (Express, Fastify, NestJS, etc.) Many examples hard-code a port, such as app.listen(3000). Always read the port from the environment in production:
const port = process.env.PORT || 3000;
app.listen(port);
Python (Flask, Django, FastAPI) Dev servers often run on fixed ports (5000, 8000, …) and are not meant for production. In production you typically use Gunicorn, Uvicorn, etc. Configure your application server to bind to PORT, for example:
gunicorn "myapp:app" --bind 0.0.0.0:$PORT
.NET / ASP.NET Core By default Kestrel binds to URLs from configuration or ASPNETCORE_URLS (and dev profiles often hard-code ports in launchSettings.json). Ensure your app listens on PORT. A simple option is to set ASPNETCORE_URLS in your container, for example:
ASPNETCORE_URLS=http://0.0.0.0:$PORT
or read PORT in Program.cs and configure Kestrel accordingly.
Go / other custom HTTP servers You typically choose the port in code when calling ListenAndServe or equivalent. Read PORT from the environment and fall back to a sensible default, for example:
port := os.Getenv("PORT")
if port == "" { port = "4000" }
http.ListenAndServe(":"+port, handler)

If you see 502 errors or "connection refused" when deploying, one of the first things to check is whether your app is actually listening on the port specified by PORT.

Example repositories

Want to quickly try a deploy with a codebase and a working Dockerfile? Currently there is one example for this purpose: