Appearance
Deploy a Web Service
A Web Service is a long-running process Infrly builds from your repo and keeps running for you — an API, a backend, a server-rendered app, anything that binds to a port and stays up. If your app has no server at all (just built HTML/CSS/JS), use a Static Site instead — it's cheaper and simpler for that case.
Create the service
New Service → Web Service, then fill in:
| Field | Meaning |
|---|---|
| Repository / Branch | Which repo and branch to deploy. Every push to this branch triggers an auto-deploy. |
| Root directory | The folder containing this app, relative to the repo root. Use . if the app is the repo root — this matters most in a monorepo, e.g. backend when the frontend lives in a sibling frontend folder of the same repo. |
| Runtime | Node, Python, Go, Java, Ruby, PHP, or Rust — see Supported Languages & Frameworks for what each one assumes. |
| Install / Build / Start command | Prefilled per runtime; override any of them. See Build & Start Commands. |
| Plan | CPU/memory tier — see Resource Plans. |
Port
Your app must read its port from the PORT environment variable — don't hardcode a port. Infrly assigns PORT and injects it automatically; whatever you set it to in your app's listen call should just be process.env.PORT (Node), os.environ["PORT"] (Python), etc. This is the single most common first-deploy failure — see Troubleshooting.
Health checks
Once your app starts, Infrly waits for it to become ready before sending it any traffic (and before a redeploy tears down the previous version). By default this is a plain TCP check — Infrly just confirms something is listening on PORT, nothing more. This is deliberate: it's the check least likely to fail for the wrong reason.
If you set a Health Check Path (e.g. /health), Infrly switches to a real HTTP check against that exact path instead, and only a 2xx–3xx response counts as healthy. Only set this if your app actually serves something at that path — pointing it at a route that doesn't exist (including a bare / on an API-only app with no root route) will make an otherwise-healthy service fail every deploy.
What happens when you deploy
A web service deployment moves through these phases, visible live in the deployment's log stream:
QUEUED → CLONING → INSTALLING → BUILDING → PACKAGING → DEPLOYING → STARTING → HEALTH_CHECKING → CONFIGURING_DOMAIN → CONFIGURING_SSL → RUNNING
If a build fails, the log tells you whether it happened while installing dependencies or while running your build command — check that phase's output first. If the build succeeds but the app never reaches RUNNING, the deployment log includes your app's own recent output (its crash log), which is almost always the fastest way to see what actually went wrong.
Redeploys don't take your app down
A redeploy (a new push, or a manual Redeploy click) starts the new version alongside the still-running previous one, and only switches traffic over once the new one passes its health check. If the new version never becomes healthy, the previous one just keeps serving — nothing is torn down until a replacement actually proves itself. See Auto-Deploy & Redeploys.