Dokku Release 0.24.0
Dokku version 0.24.0 was released earlier this week with a few new features that some power users may find useful. We'll go over major changes below.
If you're using Dokku - especially for commercial purposes - consider donating to project development via Github Sponsors, OpenCollective, or Patreon. Funds go to general development, support, and infrastructure costs.
Change exit code when app does not exist¶
This will allow wrappers around dokku to avoid needing two calls to dokku - one for apps:exists, the other for the command you want to run itself - to see if the app does not exist or if the error was something else.
Builders of UI systems on top of Dokku may wish to take advantage of this functionality to decrease the number of calls they need to make to Dokku.
Finally, plugin developers should always use
verify_app_name() (shell) and
common.VerifyAppName() (go) when verifying the app name to ensure they also receive this same functionality.
Support for heroku's
postdeploy deployment task¶
Our existing deployment task support covered a wide range of use cases, but of course did not implement Heroku's own
postdeploy support. This deployment task is commonly used to seed data into apps, especially for Heroku's "review app" functionality.
As of 0.24.0, Dokku implements support for Heroku's
postdeploy hook. This is currently triggered during the
postdeploy on the first deploy of an app, mimicking heroku. It currently happens after the
release task, during the
pre-deploy trigger, which more or less mimics the
Git Authentication handling via .netrc¶
With the new
git:sync functionality introduced in
0.23.0, users of private repositories immediately saw an issue with their ability to use the feature. To enable those users to deploy private apps, the
netrc binary was built, and a wrapper
git:auth command was added to Dokku.
This new command allows users to specify custom git server authentication information for use with
git:sync by modifying the
~dokku/.netrc file. The alternative is to use ssh keys, which is still supported.
This PR additionally outputs an error message when we detect an auth error:
This should allow folks to figure out what they need to do.
Lastly, the clone/fetch commands no longer use
Simplified docker image deployment via
There are a ton of people that want to deploy a docker image. To do that, they currently need to:
- pull the image via
ps:rebuild, which ignores
- avoid git repositories, which will result in breaking
The above doesn't quite work without root server access, so anyone who only exposes the dokku user cannot use the above workflow without an extra plugin.
They can also do a git repository workflow - creating a repository, updating it with the built image, pushing it - but there are more than a few steps needed to do that correctly and keep history.
Pull Request #4450 implements
git:from-image. Under the hood, this command creates or updates the git repository for the app with the specified image. The workflow implements all the above steps for users in a way that allows ignoring direct exposure of
docker pull as a Dokku command (which would open the flood gates to all docker commands). It also keeps the git workflow (so you get history) and enables a whole class of users to properly deploy docker images.
There is other stuff this might enable, like an app library, but the main idea is to enable a class of users that has been typically under-served.
tags plugin users, note that this functionality deprecates the
tags plugin, which will be removed in the next minor release. Please migrate any workflows currently using the
tags plugin to
Simplified archive deployment via
git:from-image - and using the same internal infrastructure to manage history - there is a new
git:from-archive command. This new command supports deploying
.zip files to apps, keeping git history with every deploy. In addition to a url, it also supports piping the archive in via stdin.
git:from-archive command is meant to be used in cases where the deployment model is to deploy from a git tag. This may mean that the artifact is already built and just needs extraction, or can continue to use the normal build process available in Dokku.
tar plugin users, note that this functionality deprecates the
tar plugin, which will be removed in the next minor release. Please migrate any workflows currently using the
tar plugin to
Specifying app builders¶
Dokku currently supports three different types of app builders:
- Herokuish (for Buildpack Heroku v2a compatibility)
- Pack (for Cloud Native Buildpacks compatibility)
The specification of the app builder is somewhat hard-coded and actually annoying for users that wish to use a specific builder for their app. In addition, it was impossible to inject your own custom builder, frustrating folks that have very specific constraints about how they generate Docker images.
Rather than hardcode the various builders, this new feature allows builder plugins to specify a
builder-detect trigger. This trigger can be used to specify if the builder should or should not be used for an application. Each builder takes the app directory and can decide if it should emit it's own image source type.
If the final list of detected builders is empty, then Dokku will default to herokuish (and
pack/CNB once that is stable). Users may also override the builder via the
This change enables users to build custom builder plugins and have those plugins used for building an image asset. By way of example, an enterprising user could create a
builder-lambda based on lambci, and then pair this with a scheduler plugin that updates a lambda function on AWS. Alternatively, a user might decide they wish to place their Dockerfile in a specific directory for their applications - such as an
_infrastructure directory - and create a plugin to override how that is detected within Dokku.
An enterprising user has already built a
builder-nix plugin that builds Docker images via NixOS.
Parallelism for some proxy commands¶
Being able to specify
--all and increase parallelism of save commands is always great. As of 0.24.0, the commands
proxy:build-config now support the
--all flag in addition to general parallelism.
If parallelism is needed for a specific command, please file an issue to get it added :)
As with every upgrade, please see the 0.24.0 migration guide for more information on upgrading to 0.24.0.
The Next Minor Release¶
Our next release will continue on the 16 outstanding 1.0 issues. We hope to knock out a few of these, especially those related to Dockerfile and ports handling. We encourage folks to take a peak at them and help investigate bugs, come up with work plans, or contribute PRs where possible to help bring us over the finish line.
As always, please post issues with bugs or functionality you think Dokku might benefit from. As well, feel free to hop into Github Discussions or Slack channel if you have questions, comments, or concerns.