Your HTTP app.A clearer path to live.

Node.js source, a Worker at runtime.

A Node.js project can mean an HTTP server, a scheduled script, a native image processor or a long-running queue consumer. They are not interchangeable hosting workloads. Fortly supports selected JavaScript HTTP frameworks by building their source into a Worker that serves requests.

Express, Koa, NestJS and Fastify projects run as Node apps: Fortly adopts the HTTP server your code starts, on the same runtime as everything else. Hono and Elysia export request handlers instead of opening their own server socket. Astro, SvelteKit and Angular built for Node run the same way, and a Nuxt, Nitro, Analog, Angular, React Router or TanStack Start build that fails for Workers is retried as a Node app. It is not a promise to run every Node.js operating-system API or an arbitrary daemon unchanged.

Native packages run through Fortly Bridge: sharp, sqlite3, bcrypt, argon2, canvas and onnxruntime-node execute in a sandboxed process on the server, and your app calls them as if they were local. The build log names every package served this way and any package it cannot serve.

Give the adapter a clear entry point.

For a small Express app, keep a start script and a real server file in the repository. The adapter needs to see the HTTP server you start. Use a numeric port or a numeric fallback; do not use a Unix socket or port zero. If you start multiple servers, the last one is the application Fortly routes requests to.

import express from "express";

const app = express();
app.get("/health", (_req, res) => {
  res.json({ ok: true });
});

app.listen(process.env.PORT || 3000);

This example is an HTTP health endpoint, not a benchmark or a live service preview. Use "type": "module" in package.json for the import syntax above, and a script such as "start": "node server.js". Keep Express in your dependencies. A build script is optional for these server frameworks; when one is present, Fortly runs it.

For a compiled app, make the generated entry point unambiguous. The builder looks for a start-script target, then the main file and supported common output paths. A custom start command is an executable and its arguments, not a shell script: pipes, redirects and inline environment assignments do not belong in that field.

Deploy the source and follow the same release.

1. Choose New project → GitHub repository, connect GitHub and select the repo and branch. For an existing app, open deployment setup from Overview or Deployments.
2. Review the detected framework and package manager. Keep the project’s package.json and lockfile together at the source root.
3. Add the environment values the application needs, with a scope appropriate to the build or runtime.
4. Confirm Create and deploy or Deploy release. Read build output in the selected release, then open the HTTPS address after publication.

Repository deployments install dependencies and build on Fortly. For archive deployments, send source without node_modules when the application needs a server build. Skipping the supported server build path does not create a runnable Worker. The GitHub deployment guide covers source selection and push-to-deploy in more detail.

Keep configuration and data access intentional.

Store application configuration under Deployments → Variables. Runtime-only is suitable for values read only by your server. A build receives values scoped to Build only or Build & runtime, so do not send a secret to a build unless that build genuinely requires it. Some variable-name changes require a new Worker build; follow the environment guide for when edits take effect.

A Worker with a provisioned project database receives DATABASE_URL and can use supported PostgreSQL drivers inside a request. Follow the Worker connection guide for client lifecycle and compatibility. For HTTPS access, use a scoped Data API role when that fits; an account management token has broader authority and belongs only in trusted server code. A public browser view can use a publishable key with explicit table grants instead. These identities have different authority.

For a healthy first release, verify one application route, one expected data read and the runtime output from those requests. Build logs explain installation and compilation; application logs explain what the published request handler did. Do not keep rebuilding an app whose build succeeded when the error is actually an access grant or a runtime assumption.

Give the next incident a shorter path.

The Overview application card shows the live or in-progress release. Follow build opens release-specific output; Observability → Logs → Runtime opens application output. Logs are bounded, so download anything you need for a lasting incident record.

If the new build fails, an already live release remains available. Compare the failing commit and its first meaningful error with the previous successful release. Review a rollback before using it: restoring the application version does not roll back database rows, uploaded files or current configuration. The failure guide separates infrastructure, install, build, publish and runtime problems.