Docker and builds
Make your build reproducible and your container compatible with Deplexo's runtime.
Choose a build method
Section titled “Choose a build method”Bring a Dockerfile for explicit control over system packages, compilation, assets, and startup. Framework-generated builds are useful when standard install, build, and start steps fit your application.
Select the intended method in the dashboard. When Dockerfile is selected, the repository must contain it at the configured path. Adding framework settings alone does not override an explicitly selected Dockerfile build.
Build a reproducible image
Section titled “Build a reproducible image”Commit dependency lockfiles and use clean install commands such as npm ci. Use multiple build stages to keep compilers and development dependencies out of the runtime image. Copy dependency manifests before source so unchanged dependencies can reuse build cache.
Use .dockerignore to exclude local dependencies, build output, git history, credentials, and editor files. Install dependencies while building the image; the runtime filesystem is read-only and is not intended for package installation.
node_modules.nextdist.git.env.env.*!.env.example*.log
Start the correct process
Section titled “Start the correct process”Use an exec-form CMD so the application process receives termination signals. Run a production server or compiled binary, not a development watcher. Web applications must listen on 0.0.0.0 and the configured PORT; exposing a Dockerfile port does not make a server listen on it.
Background processes should run in the foreground until stopped. Avoid scripts that launch the actual worker in the background and immediately exit.
CMD ["node", "server.js"]
Test runtime permissions
Section titled “Test runtime permissions”Use an unprivileged image user and ensure it can read packaged assets. Containers run without added capabilities and with a read-only root. Writable locations are the temporary directory and configured persistent mount.
Ensure the image user can write where the app needs to persist data. Compiled application binaries belong in the image, because the temporary and data mounts are not executable. Test with these constraints before deployment.
Diagnose build failures
Section titled “Diagnose build failures”Read the first failing build step and the preceding lines. A missing lockfile, case-sensitive path mismatch, absent package script, or incorrect root directory can explain a build that worked locally.
Reproduce the build from a fresh checkout and committed files. Check the failing command and resource usage before changing limits. A successful image build still needs a working start command and runtime configuration.