How to Deploy a Next.js App on aidrop.it

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Deploy a Next.js app as a standalone Node.js server, package its assets into the image, and check every route that writes a cache. On aidrop.it, the application directory is read-only. A homepage that loads once does not prove that image optimization, revalidation, or a form will work after deployment.

Start with one small site: a homepage, a pricing page, and a server-rendered status route. Connect your coding agent through the quickstart, choose a Project with hosting capacity, and push the repository. The first deployment walkthrough covers the connection and build loop.

1. Package the server and its assets

Enable standalone output in the project's existing Next.js configuration. Build with the Node.js version and lockfile the repository expects, then copy the generated server and static assets into the final container. Run that image locally before uploading it; missing CSS is easier to diagnose before a domain enters the picture.

// Merge into the existing next.config.mjs configuration.
const nextConfig = { output: 'standalone' };
export default nextConfig;

The standalone output documentation explains the layout: .next/standalone contains the server, but public and .next/static need separate copies. In the final image, place them at public and .next/static beside server.js; skip public only if the project has no such directory. Start with node server.js, HOSTNAME=0.0.0.0, and PORT=3000.

2. Decide what can change at runtime

Separate public build configuration from server secrets before the first build. Project secrets arrive when the Service runs. They cannot supply a value that the frontend bundle already needed during compilation. Keep private API keys on the server and avoid fetching private production data while generating pages in the image build.

Next.js embeds NEXT_PUBLIC_ values during next build; changing a runtime secret does not rewrite that bundle. Read server secrets in request-time code where needed. Default server caching can write to disk, and image optimization also needs a cache strategy. Check the self-hosting guide against the installed Next.js version.

For a first site, omit ISR and use an external image loader or deliberately disable optimization, accepting its performance tradeoff. If the application needs persistent caching, configure a compatible cache handler and verify its network access. Test the actual routes under a read-only root filesystem. /tmp is temporary scratch space; local files do not provide durable storage.

3. Build, open, and deploy a second revision

Ask the agent to call service_build with the Project, repository, and Service name for the first build. Select the Dockerfile explicitly, match the container port to the server, and use a lightweight health route. Poll the build result, then inspect runtime logs while opening the public URL and exercising the site's navigation.

Use these build settings alongside the first-call identifiers:

{
  "build_type": "dockerfile",
  "build_dockerfile_path": "Dockerfile",
  "container_port": 3000,
  "health_path": "/",
  "required_secret_names": []
}

For an app with private integrations, store their values through project_secret_set and list the required names before building. Poll service_get; use service_logs for failures. The first successful deployment has a public address, so protect private routes in the application from the start.

Change one sentence, push another commit, and build the existing Service by ID. Verify the new text, a direct visit to a nested route, static assets, and a server-side request. Record the deployed commit and URL so the next change starts from a known revision.

Copy this Next.js deployment brief

Give this brief to the agent with the repository and Project names filled in. It keeps the deployment bounded to the current application and makes cache behavior part of acceptance. Keep the completed checklist in the repository; do not record secret values or claim a route passed without opening it.

Deploy repository <repo> into Project <project>.
[ ] Preserve its Node.js version, package manager, and lockfile.
[ ] Enable standalone output; package public and .next/static.
[ ] Bind the production server to 0.0.0.0:3000.
[ ] Separate public build values from private runtime secrets.
[ ] Check ISR, image optimization, and other filesystem writes.
[ ] Exercise those routes with a read-only application directory.
[ ] Build through the Dockerfile and inspect build/runtime logs.
[ ] Verify homepage, nested route, assets, and server request.
[ ] Deploy a second commit and verify its visible change.
Report the URL, commit, checks passed, and unresolved failures.

FAQ

Do I need a static export? No. Standalone output runs a Node.js server and can support server-rendered routes. A static export suits sites whose features can run without that server.

Can aidrop.it inject private API keys? Yes. Store them as Project secrets and select their names in required_secret_names. They are runtime values; never expose them through a NEXT_PUBLIC_ variable.

Why does the page load without its styles? Check that the final image contains .next/static and any files from public in the locations the standalone server expects. Inspect the failed asset URLs before changing routing.