New as of 0.3.15
While Dokku normally defaults to using heroku buildpacks for deployment, you can also use docker's native
Dockerfile system to define a container.
Dockerfile support is considered a Power User feature. By using Dockerfile-based deployment, you agree that you will not have the same comfort as that enjoyed by Buildpack users, and Dokku features may work differently. Differences between the two systems will be documented here.
To use a dockerfiles for deployment, commit a valid
Dockerfile to the root of your repository and push the repository to your Dokku installation. If this file is detected, Dokku will default to using it to construct containers except in the following two cases:
BUILDPACK_URLenvironment variable set via the
dokku config:setcommand or in a committed
.envfile. In this case, Dokku will use your specified buildpack.
.buildpacksfile in the root of the repository. In this case, Dokku will use your specified buildpack(s).
Changed as of 0.5.0
Dokku will extract all tcp ports exposed using the
EXPOSE directive (one port per line) and setup nginx to proxy the same port numbers to listen publicly. If you would like to change the exposed port, you should do so within your
Dockerfile and app.
Note: Nginx does not support proxying UDP. UDP ports can be exposed by disabling the nginx proxy with
dokku proxy:disable myapp
If you do not explicitly
EXPOSE a port in your
Dockerfile, Dokku will configure the nginx proxy to listen on port 80 (and 443 for TLS) and forward traffic to your app listening on port 5000 inside the container. Just like buildpack apps, you can also use the
$PORT environment variable in your app to maintain portability.
When ports are exposed through the default nginx proxy, they are proxied externally as HTTP ports. At this time, in no case do we proxy plain TCP or UDP ports. If you would like to investigate alternative proxy methods, please refer to our proxy management documentation.
By default no arguments are passed to
docker run when deploying the container and the
ENTRYPOINT defined in the
Dockerfile are executed. You can take advantage of docker ability of overriding the
CMD or passing parameters to your
$DOKKU_DOCKERFILE_START_CMD. Let's say for example you are deploying a base nodejs image, with the following
You can do:
dokku config:set node-js-app DOKKU_DOCKERFILE_START_CMD="--harmony server.js"
To tell docker what to run.
false will enable or disable docker's image layer cache. Lastly, for more granular build control, you may also pass any
docker build option to
docker, by setting
New as of 0.5.0
You can also customize the run command using a
Procfile, much like you would on Heroku or
with a buildpack deployed app. The
Procfile should contain one or more lines defining process
types and associated commands.
When you deploy your app a Docker image will be built, the
Procfile will be extracted from the image
(it must be in the folder defined in your
/app) and the commands
in it will be passed to
docker run to start your process(es). Here's an example
web: bin/run-prod.sh worker: bin/run-worker.sh
FROM debian:jessie WORKDIR /app COPY . ./ CMD ["bin/run-dev.sh"]
When you deploy this app the
web process will automatically be scaled to 1 and your Docker container
will be started basically using the command
docker run bin/run-prod.sh. If you want to also run
a worker container for this app, you can run
dokku ps:scale worker=1 and a new container will be
started by running
docker run bin/run-worker.sh (the actual
docker run commands are a bit more
complex, but this is the basic idea). If you use an
ENTRYPOINT in your
Dockerfile, the lines
Procfile will be passed as arguments to the
ENTRYPOINT script instead of being executed.