Deployment Workflow

Source intake and build execution

Every deployment starts from a selected repository state. This creates a direct link between application behavior and source changes.

Build steps run from the commands you configure. Failures are surfaced early and prevent unstable releases from progressing.

Runtime-specific project configuration

Deployment behavior depends on the selected service type. Teams should configure commands and publish settings explicitly instead of treating every repository like the same runtime.

Apployd can auto-detect several production defaults, but the most reliable workflow is to declare the correct project type, root directory, and runtime-specific fields up front.

• Node Web Service: start command detection prefers start:prod, start, serve, package.json main, then compiled entries such as dist/server.js. Dev commands are not valid production startup commands.
• Python: dependency install supports requirements.txt, Pipfile, pyproject.toml, and setup.py. Entrypoint detection covers Django, Flask, FastAPI, wsgi.py, asgi.py, then main.py or app.py.
• Static Site: Apployd builds the frontend output and serves the configured publish directory with nginx and SPA fallback to index.html.

Release status lifecycle

Operators can monitor deployment progress through clear status stages such as queued, building, deploying, ready, failed, or canceled.

This gives teams a shared operational language during releases and incident response.

Rollback and cancellation controls

When a release is risky or degraded, teams can cancel in-progress deploys or roll back to the previous healthy state to reduce impact.