Web Services
Host dynamic web apps and APIs — Express, FastAPI, Django, Rails, Go, Rust, whatever you use — at a public HTTPS URL. Deploy from Git or a prebuilt Docker image.
Muerte Cloud builds and deploys your code on every push to the branch you link. Every web service gets a unique *.muerte.app subdomain and can attach any number of custom domains with fully managed TLS. Services in the same project talk to each other over a free private network — no VPC to configure, no public exposure.
0.0.0.0 to receive traffic from the public internet. The default expected port is 8080 and is passed to your process as the PORT environment variable. See Port binding.Deploy a template#
The fastest way to try the platform is to deploy one of the starter templates. Each one is a minimal, real app in the given stack with the correct build and start commands preconfigured:
Deploy your own code#
You can deploy a web service from a linked GitHub, GitLab or Bitbucket repository, from a public Git URL, or from a prebuilt Docker image in any registry.
- 1Connect your Git providerSign in to the Muerte Cloud dashboard, open
New → Web Serviceand connect your GitHub, GitLab or Bitbucket account. Both public and private repositories your account can access are supported. - 2Pick a repository and branchChoose the repository and the branch that should be auto-deployed. Every push to that branch triggers a new build.
- 3Fill in the service form
Field Description Name A name for the service inside the Muerte Cloud dashboard. It is also used as the default *.muerte.app subdomain. Region The geographic region where the service runs. Services in the same region and project share a free private network. Branch The Git branch to build. Every push to this branch triggers a new build and deploy. Language The runtime for your app. Muerte Cloud auto-detects Node.js, Python, Go, Ruby, Elixir, Rust, PHP and .NET — or use a Dockerfilefor anything else.Build Command Command that produces build artifacts. Typical values: npm ci && npm run build,pip install -r requirements.txt.Start Command Command that boots your HTTP server. Typical values: node dist/index.js,gunicorn app.wsgi. - 4Choose an instance typeInstance types range from a small shared instance to dedicated CPU tiers with autoscaling. You can change the instance later at any time without downtime.
- 5(Optional) configure advanced settingsSet environment variables and secrets, attach a persistent disk, configure a health check path, enable pull-request previews, and pin a specific runtime version.
- 6Create the serviceClick Create Web Service. Muerte Cloud kicks off the first build; you can watch progress in real time on the service's
Deploystab.
127.0.0.1 instead of 0.0.0.0, or a build that runs out of memory on the selected instance. Check the build and runtime logs on the Deploys tab — every failure links directly to the offending log line.Port binding#
Every web service must bind an HTTP server to a port on host 0.0.0.0. Muerte Cloud's edge terminates TLS, then forwards inbound requests to your container over HTTP on that port. The container itself is never reachable directly from the public internet.
We recommend binding to the port defined by the PORT environment variable — this way you never have to hard-code a value and it works both locally and in production.
const express = require("express");
const app = express();
const port = process.env.PORT || 8080;
app.get("/", (req, res) => {
res.send("Hello from Muerte Cloud");
});
app.listen(port, "0.0.0.0", () => {
console.log(`listening on ${port}`);
});| Field | Description |
|---|---|
| Default port | 8080. Overridable from the service settings when a framework insists on a specific default. |
| Bind address | Always 0.0.0.0. Binding to 127.0.0.1 or localhost makes the service unreachable and fails the deploy. |
| Auto-detection | If your app binds to a different port, Muerte Cloud usually detects and uses it automatically. When detection fails, the deploy is marked unhealthy with a link to the log line where the bind was expected. |
| Reserved ports | 18012, 18013 and 19099 are reserved by the platform runtime and cannot be bound. |
Binding to multiple ports
A web service exposes exactly one public HTTP port. A service can bind additional ports for use over the private network — internal admin interfaces, gRPC servers, metrics scrapers — but the public listener must always bind to $PORT.
Connect to your web service#
From the public internet
Every service gets a stable HTTPS URL of the form https://<service>.muerte.app. You can attach one or more custom domains at any time; TLS certificates are issued and renewed automatically, including wildcards.
The edge terminates SSL, then forwards to your container over HTTP. Requests that arrive over plain HTTP are redirected to HTTPS before forwarding.
From other services in your project
Services in the same project can reach each other over the private network using the service name as the hostname — no ingress fee, no public exposure. From a worker, a call to a service named api looks like this:
curl http://api:8080/healthAdditional features#
Web services on Muerte Cloud also include, out of the box: