Override command or entrypoint

Your deployments will specify either a command (CMD), an entrypoint (ENTRYPOINT), or both to identify the command or executable to run in your built image. Commands or entrypoints will be either defined in your Dockerfile, generated by the buildpack, or defined by a Procfile (for buildpack builds). In many cases you will not need to change these settings from the default.

Overriding the command or entrypoint in an individual service or job allows you to run a built image without updating the Dockerfile or re-building it, or affecting any other deployments of the image. This allows you to run different services or jobs from the same repository, for example if you have a repository containing microservices or need to run a migration.

Entrypoint and command overrides can be combined when required, for example if you want to run shell commands or use variables.

You can configure the Docker runtime mode when creating a deployment (combined service, deployment service, or job) to override the default command and/or entrypoint at runtime. You can set the Docker runtime mode for existing services and jobs from the CMD override page.

If your Dockerfile defines an ENTRYPOINT instruction , the entrypoint instruction and parameters will be processed first, then any CMD instruction and parameters. The executed command in this case is a concatenation of the entrypoint and command instructions.

You can override the default command from the CMD override page in your job or service by selecting custom command as the Docker runtime mode.

Enter the new command and save changes to restart your containers with the new command. To use the default command again, select default configuration as the runtime mode and save changes to restart your deployment. Jobs will use the new configuration the next time they run.

You may need to also override the entrypoint, if one exists, to execute your command successfully.

Command override format

The Docker CMD instruction is run in exec form on Northflank, where the executable and parameters are given as elements in an array:

CMD ["executable", "parameter1", "parameter2"]

You can override the default entrypoint from the CMD override page in your job or service by selecting custom entrypoint as the Docker runtime mode.

Enter the new entrypoint and save changes to restart your containers with the new entrypoint. To use the default entrypoint again, select default configuration as the runtime mode and save changes to restart your deployment. Jobs will use the new configuration the next time they run.

You must explicitly invoke a shell if you want to execute a shell command for a Docker image. This allows you to use shell primitives and command evaluations in your Docker command, and to access environment variables in your command. You can also chain multiple commands using shell operators (for example && or ||) using this method.

You should select custom command & entrypoint as your Docker runtime mode and invoke a shell (e.g. sh -c) as the custom entrypoint. You can then include your shell command as a custom command, as a string wrapped in quotation marks (' or ").

You can include the shell and command as a command override only, but if there is an existing entrypoint it may prevent the shell from being invoked. Overriding the entrypoint is good practice to avoid this, and you should check your command has been parsed as expected before saving your override.

You can use variables in your commands to access any variables injected into your runtime environment.

To access runtime variables in a command override you should invoke a shell (sh -c) using a custom entrypoint and include the custom command with variables as a string.

The buildpack builder will attempt to identify all processes and their associated commands in your repository, and will define them in the built image, with the web process as default. You can check a default process has been set in the build logs.

You can also manually define processes and their commands in a Procfile .

If you want to run a non-default process you can specify this process using the entrypoint override.

If your built image does not define a default process then the entrypoint of the generated image will be /cnb/lifecycle/launcher. In this case you must set a command override to one of the non-default processes, otherwise the container will not start properly. The launcher will attempt to run any command with a bash shell. To execute a command without a shell, prefix the command with -- (e.g. -- /cnb/process/non-default).