From your Next.js repo.To the app people use.

Choose the output your application needs.

Next.js can produce a server-rendered application or a set of static files. Decide which one your project actually needs before changing hosting settings. A dashboard with server routes has different requirements from a generated landing page, even if both were created with Next.js.

Default Next.js projects do not need an extra configuration file simply to be detected. Fortly recognizes Next.js from the project dependencies. A static export uses your own build script; its generated directory must contain index.html. A server build is packaged for Fortly’s Worker runtime, so a traditional Node process or provider-specific backend is not automatically carried over.

For a static export, review every route that needs request-time data or server behavior. If the app needs that behavior, keep a supported server-rendered build rather than treating an export flag as a shortcut to fixing a failed server deployment.

Make the first release easy to inspect.

1. Use a clear source root. Keep the app’s package.json, lockfile and Next.js source together in the selected project directory.
2. Choose GitHub or an archive. New project opens the same source setup used by an existing project’s new deployment. Select the intended branch and review the framework.
3. Set build configuration before confirming. Add values your build needs, especially public variables embedded into browser files.
4. Follow Source, Build and Publish. A release that is still building has not become the live application. Open its build output and wait for publication before testing the URL.

Fortly uses the declared package manager or lockfile and installs dependencies in an isolated workspace. Build dependencies are installed even when NODE_ENV is production. If a frozen install finds a stale lockfile, the build can resolve dependencies in its disposable copy and records that fallback in the output; this does not rewrite your repository.

Public HTTP/HTTPS assets needed by build scripts can be fetched through Fortly’s controlled build proxy. That includes common font and data downloads. A dependency that relies on a private network destination or a custom client that ignores proxy settings still needs an explicit compatibility check.

A public variable is part of the browser build.

A NEXT_PUBLIC_ value is configuration for client-side code. Next.js can write it into generated browser assets at build time. Mark it Build only or Build & runtime when the build needs it; setting a runtime-only value after compilation cannot repair an already built browser bundle.

Do not put an account API token into a NEXT_PUBLIC_ variable. Fortly’s publishable Data API key and its account API token are not interchangeable. For server-only values, review the application’s runtime variable names before deploying; a new name may need a new Worker build.

Connect the data with the right identity.

The PostgreSQL workspace gives your project tables, SQL tools and reviewed API access. Next.js Workers can use the project database through DATABASE_URL with supported drivers, including Prisma 7 with its PostgreSQL adapter and Drizzle. Open connections inside requests and review Worker-specific client setup; an existing global connection pool may need changes. Scoped HTTPS Data API roles are another option. See native Worker database connections.

For public records, create the table, add the records and enable only the operations needed by the browser’s publishable key. Review and apply that grant before testing the endpoint. A same-origin client request can then read the table on the project’s own hostname:

const response = await fetch("/_data/projects?select=id,name", {
  headers: {
    Authorization: `Bearer ${process.env.NEXT_PUBLIC_FORTLY_KEY}`
  }
});
if (!response.ok) throw new Error("Project request failed");
const projects = await response.json();

This client-side example assumes you have applied a Public Read grant to the projects table. For user-specific rows, connect a trusted identity provider and review role grants and row policies instead of opening all rows to Public. Use the server data API for account-authorized server operations.

A clean build is one part of a working migration.

Inventory provider-specific services before moving an existing app. Pages Functions are compiled and served beside a static export, and a D1 binding is the project’s own database, with its migrations applied on each release. Durable Objects and other bindings Fortly does not provide need a migration plan; Fortly reports the missing requirements rather than publishing a frontend with broken backend routes.

After publication, test a rendered page, a server route and the app’s actual data access. Inspect runtime output for those requests. If an update fails to build, an already live release keeps serving. A rollback restores application code, not database changes or files, so keep data migrations compatible with the release you may need to restore.