From 43448c9e6d6ab1b7788f698c17cbc402bcba6b1d Mon Sep 17 00:00:00 2001 From: Dokku Bot Date: Tue, 16 Jan 2024 15:39:19 +0000 Subject: [PATCH] chore: regenerate blog --- blog/2023/dokku-0.31.0/index.html | 1 - blog/search/search_index.json | 2 +- blog/sitemap.xml | 40 +++++++++++++++--------------- blog/sitemap.xml.gz | Bin 373 -> 374 bytes 4 files changed, 21 insertions(+), 22 deletions(-) diff --git a/blog/2023/dokku-0.31.0/index.html b/blog/2023/dokku-0.31.0/index.html index 695e6fc16..87d24261a 100644 --- a/blog/2023/dokku-0.31.0/index.html +++ b/blog/2023/dokku-0.31.0/index.html @@ -2190,7 +2190,6 @@

Short-term project re-prioritizati
  • There are a number of open issues in official plugins that have thus been ignored. This has been an annoyance for more than a few users, and greatly diminishes the quality of the overall project.
  • Dokku now has a ton of features but the Kubernetes and Nomad plugins implement but a fraction of them - missing are cron support, better healthchecks, and much more.
  • Issues blocking a 1.0 release haven't decreased drastically over the past few years. Dokku itself is rock-solid, but a 1.0 label will ease anxieties for users upgrading Dokku.
    • -
  • On a personal note, I've taken a job at Porter, which offers a best-in-class experience around managing a highly-scalable PaaS on your own cloud provider. This will provide me an opportunity to take my learnings from building the best-in-class single-server PaaS to teams and companies that need a rock-solid platform that scales as they scale.

    • With all of the above in mind, the next few months will be spent on enhancing Dokku Pro, implementing long-desired functionality in the official plugins, burning through 1.0 blockers, and bringing the Kubernetes and Nomad scheduler plugins to parity with the built-in docker-local scheduler.

    Is Dokku going away? No. Development will continue unabated, just in other parts of the project. Other than Dokku Pro, no features will be placed behind any paywall, nor will features be removed from the project for any reason. Users can continue to know that Dokku will stay open source, providing a great base for busy developers to get their projects deployed so they can concentrate on building great products.

    diff --git a/blog/search/search_index.json b/blog/search/search_index.json index 8c28d0641..5aca12116 100644 --- a/blog/search/search_index.json +++ b/blog/search/search_index.json @@ -1 +1 @@ -{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"2016/resource-management/","title":"Resource Management in Dokku","text":"

    Every so often, user's ask if it's possible to use Dokku as the basis of a system where each user in Dokku would have access to only their applications. Because of various reasons, this isn't possible out of the box, though it's certainly within the realm of possibility.

    There are two requirements for such a system, one of which we'll cover here.

    Tip

    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.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#resource-management","title":"Resource Management","text":"

    A common issue you may come up against is how to limit resource usage for different applications. One user's use of memory should not cause OOM issues in another application. Similarly, you would not want a particular application to hog the network bandwidth unfairly, or saturate disk I/O.

    These are not new problems to containers, multiple users on a system, or Dokku. These same issues also occur when deploying services directly on a server, or even running applications on your computer. Remember the last time your torrenting application used up all your network and you couldn't load a web page?

    It's also a solved problem. Applications that tend to use more bandwidth end up implementing quality of service algorithms to ensure your system runs smooth, allow users access to settings which they can modify to crank up/down resource usage, or some combination of the two. Dokku is no different.

    In Dokku's case, we normally provide users with high-level porcelain to handle the low-level plumbing. This usually comes in the form of plugins (porcelain) which orchestrates docker calls (plumbing). However, we move slowly from the plumbing towards porcelain as we judge just what the requirements are and how to best expose a ui around the given problem.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#persistent-storage","title":"Persistent Storage","text":"

    Take for instance the persistent storage. Dokku has long had plugin hooks, and very specifically implemented the docker-args plugin trigger way back in the 0.2.0 era. Gradually that evolved into the current docker-args-PHASE triggers, with the following phases:

    We discovered that while providing plugin triggers is great for tinkerers, it wasn't exactly the nicest way to configure docker options. Many users ended up using a plugin by Dyson Simmons, the unofficial docker-options plugin. I even pointed users at it for a while. At some point, we decided to integrate it into the core, and it was implemented in #1080 by Michael Hobbs and released in 0.3.17.

    Even back then, the first comment was \"How do I use this to have persistent storage?\". In retrospect, yes, this is a great feature to have in the core, and the new docker-options plugin was a bit too much like shiny plumbing. While the maintainers were distracted with other issues, the hack-fix was to update the documentation to have persistent storage as the example usage.

    Dokku implemented this feature in 0.5.0 as the storage plugin thanks to Justin Clark. The interface is a nice piece of porcelain that utilizes the same plugin triggers that the docker-options plugin exposes, except handles the very specific case of attaching persistent storage. It has resulted in many fewer support requests, and I believe has provided developers with a much nicer Dokku experience.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#where-is-the-resource-porcelain","title":"Where is the resource porcelain?","text":"

    The Dokku team has yet to see a nice interface to limiting resources of the following kind:

    These are the common resources which dokku users may wish to limit for specific applications, and having a good ui is more important to us than implementing a feature off the cuff.

    We also need to consider how such a tool integrates with other Dokku features. The storage plugin works great as a standalone plugin, but it may not be ideal to have a plugin for each type of resource. As well, resource limitation in docker has a few different implementations, depending upon what your exact requirements are. Ideally the Dokku solution is a generic one which 80% of our users are happy with, and the 20% that are not can drop down to plugin triggers or the docker-options plugin.

    At the end of the day, this porcelain is defined by you, our users. Want this feature sooner rather than later? Submit a pull request with an implementation, and we'll help shepherd it along to a state where everyone will be happy to use it.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#alerting-on-resource-usage","title":"Alerting on Resource Usage","text":"

    While dokku manages the lifecycle of application containers, it does not and almost certainly will never manage monitoring and alerting on that usage. If your application does not have resource limitations in place, or hasn't run a background task in a while, or maybe just isn't running, that is your responsibility as a server operator to monitor/correct. Our recommendation here is to send logs/metrics to whatever upstream provider of metrics you prefer. Here are some awesome options:

    As many of our users have never actually maintained a server, we can certainly do more to help push our them in the right direction. In the next few weeks, we will be putting together a document that will gently push our users towards providers that may be able to take care of their needs, as well as clearly delineate where Dokku draws the line in the sand in terms of server management.

    Tip

    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.

    ","tags":["dokku","resource-management"]},{"location":"2016/welcome-to-dokku/","title":"Welcome to Dokku!","text":"

    Hi all! The dokku maintainers finally decided it was a good idea to have a blog to post thoughts on the development, evolution, and roadmap of Dokku. Our goal with these posts is to help inform you - dokku users and developers - as to where dokku is headed both internally and externally.

    Tip

    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.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-dokku","title":"What is dokku?","text":"

    Dokku is a docker-powered PaaS that helps you build and manage the lifecycle of applications.

    That is the spiel you get from our Site's metadata, the blurb on github, and even the footer on this blog. But what does it actually mean?

    Dokku is a somewhat loose set of scripts that are combined together as a sort of \"build\" pipeline. The input is your code, and the output is (hopefully) a running application. The pipeline looks something like the following:

    git push dokku master\n# magic\ncurl -kSso /dev/null -w \"%{http_code}\" \"http://your-app.example.com\" | grep 200\n
    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-magic-in-the-dokku-pipeline","title":"What is \"magic\" in the dokku pipeline?","text":"

    The \"magic\" comes from several pieces of tech:

    All three named pieces of software came from the original creator of Dokku, Jeff Lindsay. Both sshcommand and plugn are now wholly maintained by the Dokku Team, while the latter is currently under the care of Glider Labs, with maintenance being done by the Dokku Team as necessary.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-are-these-various-scripts","title":"What are these \"various scripts\"?","text":"

    It's important to note that dokku is by and large composed of shell scripts targeting modern bash. Why?

    Features are built as \"plugins\" which are triggered by plugn. For example, here are a few different official plugins:

    Plugins can be built in any language - in fact, some prototypes have been written in a hybrid of golang/bash or python. For the foreseeable future, however, we do not envision rewriting the core in another language.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-the-goal-of-dokku","title":"What is the goal of dokku?","text":"

    Dokku's goal is to provide a simple, hackable build environment for developers to quickly get their code from their laptops into the cloud. Our personal goal is to make the deployment part easy, so all you have to do is worry about writing code.

    Tip

    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.

    ","tags":["dokku","update"]},{"location":"2018/the-dokku-experience/","title":"The Dokku Experience","text":"

    Dokku has historically had no way to introspect on the state of an installation. At one point in its history, we included a \"backup\" feature, which allowed users to export - and maybe import - configuration and data. The challenge is in exposing this information in an easily parseable manner.

    Tip

    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.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#plumbing-vs-porcelain","title":"Plumbing vs Porcelain","text":"

    To understand the challenges better, it is important to note that the internal representation of the state of Dokku is very different from how users interact with it. Data is stored in either /home/dokku/APP or /var/lib/dokku. Plugins may also store data on another host, and some implementations of the config plugin actually store configuration in distributed datastores. Dokku interacts with this data via a series of plugins - written in various languages - through plugn. This hairy mess is Dokku's Plumbing.

    Externally, developers use the dokku cli to orchestrate their applications. This is a well-known interface with clear documentation and usage examples. The cli rarely changes drastically, only doing so to allow for new functionality in a way that does not break existing use. The output format also rarely changes in backwards incompatible ways. If you know how to use one Dokku installation from 2 years ago, a modern install will be extremely familiar to you. This nice interface is called the Porcelain.

    The analogy is thus: most folks using a restroom are well-acquainted with a toilet, every toilet is similar, allowing for differences in color, size, and features - a bidet could be nice, as could an auto-flush feature. Very few folks know anything about the pipes that move waste and water around, only caring when it is broken or needs updating to support newer toilet features. The important thing is that you know how to use the toilet, that it does what you expect, and that you don't need to re-learn how to use it.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#a-common-interface","title":"A Common Interface","text":"

    When you use Dokku, you'll notice a few things:

    If you use Dokku, you only need to learn those patterns once. It is easy to figure out what is available, and straightforward to introspect upon the state of the system. This translates into the following:

    One thing I didn't touch upon is that our output is more or less machine parseable. It is not in json/xml/toml, but you can easily:

    The consistency here paves the way for automation.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#interfacing-with-dokku","title":"Interfacing with Dokku","text":"

    While we have a cli aimed at humans, as developers, we yearn for interfaces computers can automate. Our next blog post will cover how developers may interact with Dokku in a declarative fashion in order to ensure that their servers and applications are configured as expected.

    Tip

    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.

    ","tags":["dokku","interfaces"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/","title":"Comparing Cloud Native Buildpacks to Herokuish","text":"

    An upcoming piece of technology in the container space is Cloud Native Buildpacks (CNB). This is an initiative led by Pivotal and Heroku and contributed to by a wide range of community members, and one that the Dokku project has been following fairly closely. CNB builds upon the buildpack \"standard\" initially developed at Heroku, modified at Pivotal for Cloud Foundry, and used/abused by the gliderlabs/herokuish project. This post goes over a small amount of history, compares buildpack implementations across vendors, and talks about the future of buildpacks as they relate to Dokku.

    Tip

    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.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#history-channel-vault","title":"History Channel Vault","text":"

    When Heroku first launched, they provided support for Rack applications, which worked fairly well for the budding Ruby community. As the Ruby community grew, this initial support started to become limiting for their users, and thus the Heroku community started reworking their internal tech to be more flexible in functionality they supported and how they launched processes, In fact, a lot of the fancy features and patterns you'll see in a modern PaaS - 12 factor apps, Procfile support, etc. - were first prototyped or promoted by Heroku. The process of detecting support, building app slugs, and releasing the built artifacts was one such initiative. Eventually, Heroku rebuilt their platform to support alternative programming runtimes as well as community contributed runtimes in what is now known as a buildpacks.

    As time marched on, the Cloud Foundry software from Pivotal picked up the buildpack tech. This would seem like an overall great thing for the community - buildpacks that have better support for enterprise environments and needs would certainly help with adoption in the corporate world - but ended up being not as great. As there was no real specification for Buildpack technology, Pivotal ended up diverging from Heroku's implementation, resulting in:

    For buildpack authors, the standards were largely compatible - and it would likely be possible to support both at once - but in practice you really only wrote a buildpack for the platform you were using. This also meant that new features for, say, the NodeJs buildpack would need to be implemented twice in order to be supported on these two platforms.

    Additionally, the buildpack spec never specified anything about the underlying platform, so building a buildpack for Heroku's platform that depends on some OS-level dependency might not work at all when used with Cloud Foundry or vice versa.

    Suffice to say, this divergence isn't great for the community, nor great for pushing the technology forward. I'll skip all the details - mostly because I don't know them! - but the emergence of containers and related technologies enabled the folks at Heroku and Pivotal to combine efforts to on a unified v3 specification, which is now CNB. Think of it as two mini lion bots coming together to form one super-bot!

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#comparing-buildpack-tech","title":"Comparing Buildpack tech","text":"

    While the new specification - still under development - provides a new, unified way to create and distribute buildpacks, there can still be differences between platforms. At this point in time, there are actually two different main \"builders\" - a collection of buildpacks - that folks in the community can use to play around with CNBs (both are based on the Bionic stack). They do provide slightly different functionality, so a comparison between them seems like a reasonable thing to do. We'll also compare CNBs to gliderlabs/herokuish, which is the main OSS implementation of the buildpack v2a technology.

    Note

    At the time of writing, Heroku's builder contains v2a buildpacks with a shim to allow them to run under the v3 specification. Additionally, there is a possibility that the organizations will collaborate on buildpacks in the future - who wants to rebuild the wheel? - but this is sort of all in the air. Please keep this in mind if reading this blog post a few months/years from the time of publication.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#installing-dependencies","title":"Installing dependencies","text":"

    For local testing, the CNB project provides the pack cli tool to simulate what would be available in a platform. There are related projects for Kubernetes and other tools in the deployment space, but pack is great for local testing, so we'll want to install that.

    # on a mac with homebrew\nbrew install buildpacks/tap/pack\n\n# everywhere else, go to the following page and download a release\n# https://github.com/buildpacks/pack/releases\n

    CNB splits buildpacks such that there is a \"build\" base image and a \"run\" base image. Apps are built within the build base image and then the layers are rebased onto the run image for distribution. This allows for the distributed image to be smaller in size, as well as avoids the need for distribution of compile-time dependencies. Both of these images need to be available on the machine that is running the build process.

    # cloudfoundry\ndocker image pull cloudfoundry/cnb:latest     # build\ndocker image pull cloudfoundry/run:full-cnb   # run\n\n# heroku\ndocker image pull heroku/buildpacks:18        # build\ndocker image pull heroku/pack:18              # run\n

    On the herokuish side, there is a single image that contains both compile and runtime dependencies. You can export a slug from the built image and run that on a system without the installed runtime dependencies, but in practice very few people do so.

    docker image pull gliderlabs/herokuish:latest # build and run\n

    Neither Cloud Foundry nor Heroku currently publish a Dockerfile for their images, so they are still somewhat of a black box. It's also not super clear from the documentation as to what the bionic stack is. We can only hope - but not assume - that these will be published for public recreation in the future.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#building-apps","title":"Building apps","text":"

    The app we'll be playing with is the node-js-getting-started app by Heroku. You can play around with your own app to see the results; also NodeJs is currently supported with both builders as well as the gliderlabs/herokuish project.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-cnb","title":"With CNB","text":"

    Building an app with CNB is the same regardless of your chosen builder, which is nice. The following command will build the app in the current directory with the Cloud Foundry builder:

    pack set-default-builder cloudfoundry/cnb:latest\npack build --no-pull --path . \"app/nodejs-cloudfoundry:latest\"\n

    Whereas utilizing the Heroku builder is not much different:

    pack set-default-builder heroku/buildpacks:18\npack build --no-pull --path . \"app/nodejs-heroku:latest\"\n

    Note that there is a volume cache used for dependencies for both buildpacks. At the time of writing, this can be computed like so:

    IMAGE=\"app/nodejs-cloudfoundry:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\n

    At the time of writing, there isn't a way to clear out that cache volume, so you can use the above method to compute the volume name. Please note that clearing this cache volume does not necessarily clear out any app image layers created, so this may not do exactly as you'd expect if you are interacting with a remote registry.

    If you are rebuilding an app using pack, you'll notice that there doesn't appear to be any caching with the Heroku builder. This might be a bug due to shim usage, and will likely be resolved in the future, but for now should expect this to be the case.

    Note

    As an aside, the buildpacks/lifecycle project - and therefore pack - creates OCI compatible images, so tooling that only works with the older Docker Image Specification may fail when using pack-built images.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-herokuish","title":"With Herokuish","text":"

    Building an image with gliderlabs/herokuish is a bit more complicated. While it is distributed as a binary and a docker image, most folks default to using the docker image. Some platforms - notably Gitlab - utilize it via a Dockerfile, but this doesn't allow you to take advantage of build cache. The below simulates the patterns used by the pack cli tool:

    # use a cache volume\n# this can also be substituted with a directory on disk\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker volume create $CACHE_VOLUME >/dev/null\n\n# run the build process\nIMAGE=\"app/nodejs-herokuish:latest\"\ndocker container run --cidfile /tmp/cid --env USER=herokuishuser -v \"${CACHE_VOLUME}:/tmp/cache\" -v $PWD:/tmp/app gliderlabs/herokuish:latest /bin/herokuish buildpack build\n\n# create your final image\ndocker container commit $(cat /tmp/cid) \"$IMAGE\"\n\n# cleanup\ndocker container rm $(cat /tmp/cid)\nrm -f /tmp/cid \n
    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#running-an-app","title":"Running an app","text":"

    This part is likely the most similar thing across all platforms. Both the CNB images utilize a special launcher process to run your process type for you, so all you really need to do is specify that process type.

    # cloudfoundry\ndocker container run -d -p 5000 --env PORT=5000 --name app.nodejs.cloudfoundry app/nodejs-cloudfoundry:latest web\n

    Docker log output on that container looks something like the following:

    > node-js-getting-started@0.3.0 start /workspace\n> node index.js\n\nListening on 5000\n

    Heroku is pretty similar

    # heroku\ndocker container run -d -p 5000 --env PORT=5000 --name app.nodejs.heroku app/nodejs-heroku:latest web\n
    Listening on 5000\n

    With herokuish, you need to execute the process type with the /start prefix. We also need to specify the USER, as this will be used by herokuish to properly set file permissions on the /app directory.

    docker container run -d -p 5000 --env PORT=5000 --env USER=herokuishuser --name app.nodejs.herokuish app/nodejs-herokuish:latest /start web\n
    Listening on 5000\n

    Startup time is a bit longer with herokuish as it will change ownership on files within the /app directory.

    Another difference between the two is the environment within which both images run in, which we'll get into next.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#inspecting-the-built-image","title":"Inspecting the built image","text":"

    Once we have a running app, lets inspect our artifact.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-cnb_1","title":"With CNB","text":"

    Executing a command on the CNB-backed containers is the same as executing a command with any other docker image. Processes are automatically invoked within the correct app environment, which is great for one-off commands.

    # cloudfoundry\ndocker container exec app.nodejs.cloudfoundry id\n
    uid=2000(vcap) gid=2000(vcap) groups=2000(vcap)\n
    # heroku\ndocker container exec app.nodejs.heroku id\n
    uid=1000(heroku) gid=1000(heroku) groups=1000(heroku)\n

    Ditto for process inspection:

    # cloudfoundry\ndocker container exec app.nodejs.cloudfoundry ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nvcap        35  0.0  0.1  34404  2856 ?        Rs   02:43   0:00 ps auxf\nvcap         1  1.2  2.2 739020 45136 ?        Ssl  02:43   0:00 npm\nvcap        22  0.0  0.0   4632   828 ?        S    02:43   0:00 sh -c node index.js\nvcap        23  0.6  2.0 573156 41896 ?        Sl   02:43   0:00  \\_ node index.js\n
    # heroku\ndocker container exec app.nodejs.heroku ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nheroku      22  0.0  0.1  34404  2856 ?        Rs   02:47   0:00 ps auxf\nheroku       1  0.9  1.7 566792 36728 ?        Ssl  02:46   0:00 node index.js\n

    Please bear in mind that PID 1 in the container will depend upon what the buildpack launches. Aside from that note, there is nothing new with CNB and pack in regards to running commands when compared to normal docker operations, so anyone familiar with Docker will feel right at home.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-herokuish_1","title":"With Herokuish","text":"

    On the herokuish platform, a process must be executed with the /exec command as a prefix. This will give you an environment that simulates running a command in the heroku stack.

    docker container exec app.nodejs.herokuish /exec id\n

    The output of the above command is:

    uid=32767(herokuishuser) gid=32767(herokuishuser) groups=32767(herokuishuser)\n

    Inspecting processes is pretty similar:

    docker container exec app.nodejs.herokuish /exec ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nroot       287  0.0  0.1   5628  2448 ?        Ssl  02:57   0:00 /exec ps auxf\nherokui+   298  0.0  0.1  34404  2844 ?        R    02:57   0:00  \\_ ps auxf\nroot         1  0.2  0.1   5628  2448 ?        Ssl  02:57   0:00 /start web\nherokui+    13  2.7  1.9 566160 40020 ?        Sl   02:57   0:00 node index.js\n

    You'll notice that, in addition to your app, there is also the /start web process. This spawns your app with the correct environment, so just a bit different from CNB containers.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#cleaning-up","title":"Cleaning up","text":"

    Removing the containers and images is relatively straightforward, as we use traditional docker commands.

    # cloudfoundry\nIMAGE=\"app/nodejs-cloudfoundry:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.cloudfoundry >/dev/null 2>&1|| true\ndocker image rm cloudfoundry/run:base-cnb cloudfoundry/run:full-cnb cloudfoundry/cnb:latest >/dev/null 2>&1|| true\ndocker image rm app/nodejs-cloudfoundry:latest >/dev/null 2>&1|| true\n\n# heroku\nIMAGE=\"app/nodejs-heroku:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.heroku >/dev/null 2>&1|| true\ndocker image rm heroku/pack:18 heroku/buildpacks:18 >/dev/null 2>&1|| true\ndocker image rm app/nodejs-heroku:latest >/dev/null 2>&1|| true\n\n# herokuish\nIMAGE=\"app/nodejs-herokuish:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.herokuish >/dev/null 2>&1|| true\ndocker image rm gliderlabs/herokuish:latest >/dev/null 2>&1|| true\ndocker image rm app/nodejs-herokuish:latest >/dev/null 2>&1|| true\n
    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#dokku-and-cloud-native-buildpacks","title":"Dokku and Cloud Native Buildpacks","text":"

    In an ideal world, all the functionality currently provided by Heroku's v2a Buildpacks and its ecosystem would immediately exist with Cloud Native Buildpacks. Unfortunately, the spec is still evolving - though nearing a v1! - and the user-base is comparatively small. If you are a buildpack author or a vendor using buildpack technology, now is likely the best time to get involved and raise concerns with the spec and ecosystem.

    That said, Dokku has active development towards the addition of CNB to the platform. In our case, we will likely have it as an experimental feature controlled through the use of environment variables, and folks will be able to switch their installations between CNB and Herokuish. This will also likely require changes to certain plugins - in particular, those that interact with the built images - but these will hopefully be fairly minimal.

    Long-term, the plan is to deprecate and eventually remove gliderlabs/herokuish support. The purpose of the Herokuish project was to allow folks to emulate the Heroku build/runtime environment. Heroku - amongst others - will be moving to CNB at some point, and already provide a shim for existing buildpacks in the new system. So in theory, any CNB platform would be able to use that shim + any tooling that supports CNB for buildpack support.

    The pack cli tool already provides a way for folks to build and run applications, and analogs for most herokuish cli commands. Given that:

    The best course of action is for Herokuish to become unsupported once pack hits a stable release. It is unlikely that support for Herokuish will continue at that point, and only general maintenance work (upgrading buildpacks) would be performed at that time. Long-term, the project will likely be archived completely in favor of the upstream CNB projects.

    There isn't any timeline for the above other than experimental support for CNB in Dokku will land at some point in the near future, so folks installing and using Dokku won't need to worry too much about the process. Long-term, there will be a migration path outlined for users, and how that impacts users will depend on how much tooling is necessary to shim in the existing ecosystem around buildpacks. We hope to keep this minimal, but sometimes you need to break some eggs to make an omelette.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#cloud-native-buildpacks-are-the-future","title":"Cloud Native Buildpacks are the future","text":"

    The Dokku project is incredibly excited about Cloud Native Buildpacks and it's implications for speeding up how we build secure applications and services. While the existing community is fairly small, the contributors are very dedicated to getting everything just right, and we expect that this will be a great boon to users of both Dokku and buildpacks in general.

    If you'd like to have a say in how the CNB initiative develops, please feel free to join in with development or comment in the Slack community - they are a bunch of very friendly folks - where much of the current development is focused.

    Tip

    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.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/dokku-0.20.0/","title":"Dokku Release 0.20.0","text":"

    Dokku version 0.20.0 - and a few follow-on bugfixes - was released this week with quite a few major improvements, mostly to proxying and networking. We'll go over major changes below.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#changes","title":"Changes!","text":"","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#code-deprecations-and-removals","title":"Code Deprecations and Removals","text":"

    As noted in the migration guide, we removed quite a few default commands. These were replaced with :help output, and :list commands were provided where possible.

    We've also dropped support for unsupported versions of Debian and Ubuntu. Dokku no longer runs tests on older versions of Ubuntu, and Debian support for older releases was completely untested. While newer packages may work in the future, users should upgrade their operating systems where possible.

    Finally, quite a bit of code was moved into golang, and as such certain shell functions are deprecated in favor of new plugin triggers. Usage will trigger warnings in logging output. Please switch to the new triggers in custom plugins where possible, as we well continue to remove deprecated code in the future.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#custom-networks","title":"Custom networks","text":"

    In previous versions of Dokku, containers could only communicate with each other through one of the following methods:

    The first option was great for apps that were architected to do message passing, but almost a non-starter for certain self-hosted apps. Even for new apps, adding an intermediate communication layer will always increase the number of problems that could occur in a system, so it was far from optimal.

    Sending traffic over the open network is not great as for many users, this would mean traffic over the internet. Sending traffic over the open network increases latency between requests, increases bandwidth usage - and costs! - and opens users to potential security issues regardless of SSL encryption. Suffice to say that this was also not a great solution.

    Adding a custom --network flag via the docker-options plugin works well enough but has a few issues itself:

    A user created a custom plugin to attach on to networks after deploy, but this also has the side effect of not supporting containers that need to talk to a specific network on boot.

    With the new network support added in 0.20.0, users can easily create/destroy attachable docker networks, and ensure apps attach to those networks at the correct time for their apps via two easy-to-configure hooks. From the documentation:

    This feature has been a long time coming - it was originally reported in 2016 - and was also a ton of work, but we hope that it provides great value to our users.

    Here is a fun incoming bandwidth chart of a user switching to the new network support for their apps:

    See the network documentation for more information

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#routing-non-web-containers","title":"Routing non-web containers","text":"

    Users wishing to route non-web containers would previously have to either hack their nginx config or use a custom plugin to try and inject location and upstream blocks into the correct place. The lack of built-in support made it difficult to support cases where there might be a websocket process, or some command-and-conquer service that exposed a tcp connection in addition to the traditional web process.

    As of 0.20.0, we now inject a custom .DOKKU_APP_${PROCESS_TYPE}_LISTENERS variable into all nginx.conf.sigil files. This will allow folks to inject http(s) processes into the nginx.conf.sigil, which brings initial support for proxying non-web processes.

    Future improvements might include tcp support - via the nginx stream module - and injection of custom location blocks for even easier proxying of non-web processes.

    Users are encouraged to switch their custom configs to use the new .DOKKU_APP_WEB_LISTENERS variable when constructing upstreams. See the nginx template documentation for more information.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#hsts-enabled-by-default","title":"HSTS Enabled by Default","text":"

    If you have an SSL certificate and are proxying requests using the nginx plugin, then HSTS will be enabled by default. It is enabled by default - including for subdomains - though without browser preloading. Please note that the default cache setting is 182 days, so pre-configure this value if you believe you will need to manipulate HSTS support.

    See the nginx hsts documentation for more information.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#restarting-docker-containers-recover-from-ip-changes","title":"Restarting docker containers recover from IP changes","text":"

    Docker has undefined behavior around IP address persistence when containers restart, either due to failure or because of server reboot. This has resulted in issues where restarting containers lose their IP addresses, breaking any proxy method that is associated with a container IP instead of the container name (read: how Dokku works!). This sometimes caused nasty issues where apps deployed on Dokku might mistakenly have their nginx route incorrect apps to users on server reboot, or just straight-up fail to serve requests even when the app is working after a container restart.

    In 0.20.2, we included the dokku-event-listener as a recommended package. It is usable with older versions of dokku, and can be installed like so:

    # update your apt repository\napt update\n\n# install it!\napt install dokku-event-listener\n

    The dokku-event-listener daemon will properly listen to container events - start, restart, delete, destroy, die - and reload the nginx config for the related app as appropriate. It will even rebuild the application if we've hit the max container restart count. It will also output debug logging that you can use to correlate application crashes with service outages.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.20.0 migration guide for more information on upgrading to 0.20.0.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#future-development","title":"Future development","text":"

    As Dokku continues to mature towards a 1.0 target, the following areas will be of greater focus in upcoming releases:

    As always, please post issues with bugs or functionality you think Dokku might benefit from. As well, feel free to hop onto our IRC or Slack channel if you have questions, comments, or concerns.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/","title":"Dokku Release 0.23.0","text":"

    Dokku version 0.23.0 was released this weekend with quite a few major improvements for many common workflows. We'll go over major changes below.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#new-core-contributors","title":"New Core Contributors","text":"

    With the new release, a few folks have been added as contributors to the project.

    These folks have been added as Github Triagers to various projects. This means they'll have increasing control over the future of the project and features they think they'd like in the core, as well as how those things might be developed over time. You can think of them as community++ :)

    While they have been added as core contributors, as this is an Open Source Project, there is no requirement of any work from them. This is simply recognition for the great work they've done to support Dokku.

    How do you join? There are a number of ways to Contribute to the project, code and otherwise. As we continue to clean up various projects under the Dokku umbrella, more folks will be added (and removed as necessary) to help push the project forward. We hope that this helps unblock pull requests from being merged, features from being developed, and bugs from being squashed.

    Thanks to the folks above and all community contributors. It would be hard to imagine Dokku without all of you pushin the project forward.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#circleci-github-actions","title":"CircleCI => Github Actions","text":"

    CircleCI was and remains a great service - we'll continue to use them for other projects unless there is a real need to switch. They certainly provide a wide-range of features, and will be the recommended CI stack for folks needing serious CI functionality.

    That said, our CircleCI usage was limited for a few reasons:

    With 0.23.0, we've switched to Github Actions, which provides the following benefits:

    While not all functionality has been carried over - in particular, test statistics are missing, it is impossible to re-run only failing jobs, and running jobs with SSH for debugging is a bit more difficult - it is hoped that the change makes the process of developing new functionality much easier for the average contributor.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#image-labeling","title":"Image Labeling","text":"

    Dokku introduced label-schema.org support as part of 0.18.0 back in August of 2019. While Label Schema is no longer actively maintained - in favor of OCI Annotations tha we'll properly support in the near future - we still label images and labels according to that spec. Unfortunately, our labeling support left a lot to be desired.

    As of 0.23.0, the Dokku project now uses docker-image-labeler to inject labels only when necessary, and avoids building new containers entirely. This should have no real impact on produced images, though will reset layer create times as a side effect (a limitation that may be removed in the future).

    We'll continue to investigate similar ways to speed up the build process for all of our users in future releases.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#libpam-tmpdir-support","title":"libpam-tmpdir support","text":"

    As part of an increased focus on security, we've added proper libpam-tmpdir support. The actual problem was due to how we attempt to drop permissions via the sudo binary without resetting certain environment variables.

    While the fix was relatively simple - just unsetting some variables - our implementation of permission dropping certainly leaves something to be desired. Enterprising individuals who wish to contribute to the project and have expertise in this area would certainly be welcomed!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#buildpack-stack-builder-management","title":"Buildpack Stack Builder Management","text":"

    In previous releases, users of derivative gliderlabs/herokuish images would need to specify a DOKKU_IMAGE environment variable in order to use their version over what we ship by default. While this was a reasonable approach that worked when there was only one herokuish image version being maintained, we've recently decided to add support for building both 18.04 and 20.04 based images. Additionally, this approach does not work at all for our Cloud Native Buildpack support.

    As of 0.23.0, there is now a way to set the stack builder image in use. Herokuish users (the majority of Dokku users at this time) will be able to specify either the 18.04, 20.04, or any other image as follows:

    # app-specific command\ndokku buildpacks:set-property $APP $SOME_IMAGE\n\n# global command\ndokku buildpacks:set-property --global stack $SOME_IMAGE\n

    Any tag listed on Docker Hub can be used, and folks can derive their custom herokuish image as needed for their own platforms. For general users, we highly recommend sticking to the shipped defaults.

    Cloud Native Buildpack users have access to the same command, and can use it to specify an alternative builder image. Below switches the global builder image from heroku/buildpacks to the packeto buildpacks maintained by CloudFoundry:

    dokku buildpacks:set-property --global stack paketobuildpacks/build:base-cnb\n

    We'll continue working to add full support for buildpacks commands to the Cloud Native Buildpack support, and hope this initial work makes it easier to use.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#container-logrotation","title":"Container Logrotation","text":"

    With the addition of Vector-based Log Shipping in 0.22.x, we still had a need to ensure logs didn't consume host resources. Assuming default docker log settings, it is now possible to set the docker log retention via logs:set:

    dokku logs:set --global max-size 20m\n

    This new setting injects a property into the docker run calls (though is exposed via trigger for alternative schedulers), defaults to 10m, and can be set both globally and on a per-app basis. Please rebuild your apps to have this come into effect.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#nginx-configuration","title":"Nginx Configuration","text":"

    While having a sane default is great, often-times users will need to customize their nginx proxy configuration to meet their needs. Vendoring a custom nginx.conf.sigil makes it more difficult for us to ship security updates to users, and thus we're opening the floodgates to new knobs for configuring the nginx config built for apps.

    The following new properties can now be set on a per-app basis:

    While the hsts property can now be set globally (default on) in addition to on a per-app basis.

    We'll continue adding support to additional properties (both globally and otherwise) as the needs arise from the community. Checkout our nginx documentation for further details.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#scheduled-cron-task-management","title":"Scheduled Cron Task Management","text":"

    For years, we've asked folks to manage a custom cron file outside of the Dokku deployment process. While this was all well and good, it doesn't work well for less technical users or those who do not have server access. We've added support to the app.json file for specifying a list of commands and the schedule for which to run said commands. Usage is simple:

    {\n  \"cron\": [\n    {\n      \"command\": \"node run some-command-here\",\n      \"schedule\": \"@daily\"\n    }\n  ]\n}\n

    Scheduled cron tasks are run within isolated Docker containers, and any number of commands can be added to a given app. While this isn't currently supported in alternative schedulers, the functionality was built with such support in mind.

    Checkout the scheduled cron task documentation for more details on how the functionality works. We'd definitely love your feedback!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#git-repository-syncing-support","title":"Git Repository Syncing support","text":"

    This is one of the more exciting features. Users may now run a command to specify a remote repository to sync - and build! - an app from via the git:sync command. This makes it possible to build webhook-like functionality by wrapping the command in a web api of sorts.

    # just sync some code, maybe to setup a repository\ndokku git:sync node-js-app https://github.com/heroku/node-js-getting-started.git\n\n# sync and build the repository!\ndokku git:sync --build node-js-app https://github.com/heroku/node-js-getting-started.git\n

    We hope to continue adding interesting git-based workflows in upcoming releases, but hope that this feature is well-used by platform developers.

    Thanks to @crisward for the inspiration via his dokku-clone project.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.23.0 migration guide for more information on upgrading to 0.23.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#10","title":"1.0?","text":"

    Our versioning is getting long in the tooth, and we're quickly winding towards an eventual 1.0 release. It's been teased in the past, but as of this writing, there are currently 18 outstanding issues in the 1.0 milestone. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/","title":"Dokku 0.23.x Wrapup","text":"

    Dokku version 0.24.0 was released earlier this week. This post covers the major changes that occurred throughout the lifetime of the 0.23.x series. A future post will cover the 0.24.0 release.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#release-changes","title":"Release changes","text":"

    Dokku now has support for triggering releases via Github Actions. This will allow any maintainer to make a release of Dokku without needing to set anything up locally. The ability to auto-release plugins and tools in the Dokku ecosystem will slowly be added to all core projects over the coming weeks.

    In addition, we now update the official Azure ARM template for Dokku during the release process, as well as bump the homebrew repo for the remote cli tool. We hope to extend this official release bumping to other image maintained for Dokku in the near future.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#report-output-as-json","title":"Report output as json","text":"

    While undocumented, all of the golang plugins now support displaying report output as json (#4369). This makes it easier for tools to parse the reports.

    A future release will hopefully extend this to all plugins, and provide a framework for non-core plugins to also have json formatting support in :report output.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#modifying-x-forwarded-ssl-in-nginx-configurations","title":"Modifying X-Forwarded-Ssl in nginx configurations","text":"

    Some load balancers require specifying a value for X-Forwarded-Ssl. The ability to do so was added in #4420. Note that this is a non-standard version of setting x-forwarded-proto to https, and should only be done as a last resort.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#add-support-for-injected-cron-entries-from-external-plugins","title":"Add support for injected cron entries from external plugins","text":"

    One of the things lost by the addition of scheduled cron task support in 0.23.0 was the ability to set cron tasks from plugins. This functionality was used by the dokku-letsencrypt plugin to support it's auto-renew functionality.

    The change in #4384 allows alternative plugins - such as dokku-letsencrypt - to inject scheduled cron tasks into the cron system used by Dokku. Cron systems can choose to include or not include a cron task based on the specified scheduler, and can also optionally use a third parameter to store arbitrary information.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#ability-to-clear-an-individual-resource-value","title":"Ability to clear an individual resource value","text":"

    As of (#4372)[https://github.com/dokku/dokku/pull/4372], a resource value can be individually cleared by setting the value to the special value clear.

    dokku resource:limit --cpu clear node-js-app\n
    =====> Setting resource limits for node-js-app\n       cpu: cleared\n
    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#a-new-null-buildpack-was-added","title":"A new 'null' buildpack was added","text":"

    Herokuish 0.5.25 introduces a new null buildpack. This buildpack does nothing, which is useful if your app vendors all it's dependencies and does not need to be built.

    To use it, include a .null file in your app repository. No other changes are necessary.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#documentation-is-now-at-dokkucom","title":"Documentation is now at dokku.com","text":"

    The documentation has moved from the global viewdocs to it's own fork, hosted at dokku.com. Future documentation changes will enable embedded docs for official plugins, doc search, as well as including the blog on the main domain.

    As an added bonus, our documentation now has SSL!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#checking-if-an-app-was-deployed","title":"Checking if an app was deployed","text":"

    Previously, checking if an app was deployed actually checked if there were any running processes. This is not only incorrect, but also fails to take into account applications that do not have running processes and are only used for one-off commands.

    The fix in #4402 migrates apps to the new \"deployed\" property which is set in core-post-deploy. The result is a slightly faster \"deployed\" check that is correct and allows non-scaled apps to actually work.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#better-procfile-extraction","title":"Better Procfile extraction","text":"

    As of #4373, the Procfile is now extracted in the pre-deploy step for every deploy and otherwise not removed. Thus, it should always exist when necessary - web will be scale to 1 automatically and it won't need to be present on future ps:scale calls since we'll have the scale file - and the command can execute faster.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.23.0 migration guide for more information on upgrading to 0.23.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    And that's it for 0.23.x. Our next post will cover 0.24.0, as well as plans for future releases.

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/","title":"Dokku Release 0.24.0","text":"

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#change-exit-code-when-app-does-not-exist","title":"Change exit code when app does not exist","text":"

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#support-for-herokus-postdeploy-deployment-task","title":"Support for heroku's postdeploy deployment task","text":"

    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 release phase.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#git-authentication-handling-via-netrc","title":"Git Authentication handling via .netrc","text":"

    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:

    There is no deploy key associated with the dokku user.\nGenerate an ssh key with the following command (do not specify a password):\n  ssh-keygen -t ed25519 -C 'example@example.com'\nAs an alternative, configure the netrc authentication via the git:auth command\n

    This should allow folks to figure out what they need to do.

    Lastly, the clone/fetch commands no longer use -qq or stderr redirection. If there are other errors, this will allow operators to have some debugging information.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#simplified-docker-image-deployment-via-gitfrom-image","title":"Simplified docker image deployment via git:from-image","text":"

    There are a ton of people that want to deploy a docker image. To do that, they currently need to:

    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.

    For 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 git:from-image.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#simplified-archive-deployment-via-gitfrom-archive","title":"Simplified archive deployment via git:from-archive","text":"

    Similar to 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 .tar, .tar.gz, and .zip files to apps, keeping git history with every deploy. In addition to a url, it also supports piping the archive in via stdin.

    The 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.

    For 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 git:from-image.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#specifying-app-builders","title":"Specifying app builders","text":"

    Dokku currently supports three different types of app builders:

    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 builder:set command.

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#parallelism-for-some-proxy-commands","title":"Parallelism for some proxy commands","text":"

    Being able to specify --all and increase parallelism of save commands is always great. As of 0.24.0, the commands proxy:enable, proxy:disable and 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 :)

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.24.0 migration guide for more information on upgrading to 0.24.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/","title":"Dokku Release 0.25.0","text":"

    With the 0.25.x release of Dokku a few weeks ago, a folks may have questions as to why they would want to upgrade and how it would impact their workflows. We've cherry-picked a few more important changes, but feel free to go through the release notes for more information.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#make-heroku-20focal-the-default-stack-for-herokuish-builds","title":"Make heroku-20/focal the default stack for herokuish builds","text":"

    With the release of newer versions of Ubuntu, the heroku-18 stack (based on Ubuntu 18.04) was getting a bit long in the tooth. We've since switched to heroku-20 as our default. Many apps will continue to work as before, though some with compiled dependencies may have issues. This may be fixed by either of the following:

    Users may also set the stack property globally by specifying --global instead of an app name.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#drop-web-installer-in-favor-of-setup-via-cli","title":"Drop web installer in favor of setup via cli","text":"

    Dokku has had a Web installer for years. This installer has been useful for getting started - especially when setup via a cloud image on popular hosting providers - but has been an open security risk for those that forget that it exists.

    Rather than try weird schemes to lock it down or notify users that it is still around, we've decided to remove it completely. It's usage is replaced by the following commands:

    # usually your key is already available under the current user's `~/.ssh/authorized_keys` file\ncat ~/.ssh/authorized_keys | dokku ssh-keys:add admin\n\n# you can use any domain you already have access to, also takes an IP address\ndokku domains:set-global dokku.me\n

    We strive to make Dokku secure by default, and this is a step in that direction.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#drop-support-for-ubuntu-1604","title":"Drop support for Ubuntu 16.04","text":"

    While our debian packages are generic enough to use on any Debian-based operating system, we've dropped support for Ubuntu 16.04 as it reached the public End of Life in April of 2021. This allows us to spend more time testing on newer systems. We've also added initial support for Debian Bullseye (in 0.25.2) for those using Debian's latest release.

    We will continue to add support for other operating systems as time goes on.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#add-support-for-the-formation-key-in-appjson","title":"Add support for the formation key in app.json","text":"

    Dokku has long had support for a DOKKU_SCALE file that tracked repo-specified scaling settings for apps. This was also the name for a file on disk that held the scale contents. Code handling whether a user could scale or not was quite brittle.

    Users may now specify a formation key in their app.json file. This is similar to heroku, and currently supports scale quantity on a per-process basis.

    {\n  \"formation\": {\n    \"web\": {\n      \"quantity\": 1\n    },\n    \"worker\": {\n      \"quantity\": 4\n    }\n  }\n}\n

    The goal here is to consolidate various app config stored in a variety of files in repo into one app.json file. We'll be following Heroku's specification around this file where possible, but will extend it where necessary - as we did with Cron support in 0.23.x.

    See the process management documentation for more information on how to use this in your apps.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#add-monorepo-support","title":"Add monorepo support","text":"

    Some users may find a need to deploy an app several times with slightly different settings each time. This generally works by setting environment variables as necessary, but some things require changing which in-repo files are used. We've made changes across Dokku to respect changing the following:

    Feel free to file issues for any other files in use by Dokku that should be changed to allow better monorepo support.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#implement-the-registry-plugin","title":"Implement the registry plugin","text":"

    Users of the new git:from-image functionality introduced in 0.24 may have noticed missing support for authenticating against remote registries. This was added in the new registry management plugin, and generally supports the same interface you'd see with docker login:

    # hub.docker.com\ndokku registry:login docker.io $USERNAME $PASSWORD\n\n# password via stdin\necho \"$PASSWORD\" | dokku registry:login --password-stdin docker.io $USERNAME\n

    Additionally, schedulers other than the docker-local scheduler require that the deployed image be available on a registry. This plugin can be used for upload images after the build process completes.

    dokku registry:set node-js-app push-on-release true\n

    Images will be pushed to Docker Hub by default. Users may specify an alternative registry by setting the server property:

    dokku registry:set node-js-app server registry.digitalocean.com/\n

    Users of the community dokku-registry plugin should uninstall that plugin before upgrading Dokku, and then ensure that their apps are re-configured with the built-in plugin.

    See the registry management documentation for more information on how to use the registry plugin.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#revamp-the-dokku-run-command","title":"Revamp the dokku run command","text":"

    The dokku run command was often misunderstood. Users assumed the containers would disappear after use, and there was no way to understand what containers were running via dokku run.

    The new release automatically includes the --rm flag on containers created by dokku run. Users wishing to run detached containers should use the dokku run:detached command.

    We also introduced the run:list command, which can be used to list all containers created by dokku run (by filtering on the com.dokku.container-type=run docker label). Users will be able to quickly see what is currently running. In the future, users may be able to enter those running containers via run:enter, and remove any errant ones via run:destroy.

    Please note that implementation and semantics of dokku run are up to individual scheduler plugins.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#routing-to-non-dokku-managed-apps","title":"Routing to non-Dokku managed apps","text":"

    In some cases, it may be necessary to route an app to an existing $IP:$PORT combination. This is particularly the case for internal admin tools or services that aren't run by Dokku but have a web ui that would benefit from being exposed by Dokku. This can be done by setting a value for static-web-lister network property and running a few other commands when creating an app.

    # for a service listening on:\n# - ip address: 127.0.0.1\n# - port: 8080\n# create the app\ndokku apps:create local-app\n\n# set the builder to the null builder, which does nothing\ndokku builder:set local-app selected null\n\n# set the scheduler to the null scheduler, which does nothing\n\n# for dokku 0.25.x\ndokku config:set local-app DOKKU_SCHEDULER=null\n\n# for dokku 0.26+\ndokku scheduler:set local-app selected null\n\n# set the static-web-listener network property to the ip:port combination for your app.\ndokku network:set local-app static-web-listener 127.0.0.1:8080\n\n# set the port map as desired for the port specified in your static-web-listener\ndokku proxy:ports-set local-app http:80:8080\n\n# set the domains desired\ndokku domains:set local-app local-app.dokku.me\n\n# build the proxy config\ndokku proxy:build-config local-app\n

    The above takes advantage of new null builder and scheduler plugins that do nothing during the build or schedule phases.

    This functionality can be used when trying to expose non-Dokku maintained services to the external world without requiring a deployed proxy. One nice side-effect is that this also means users can expose services with letsencrypt support.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.25.0 migration guide for more information on upgrading to 0.25.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 14 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/","title":"Dokku Release 0.26.0","text":"

    It's been a little over two weeks since our 0.26.x release landed. Here is a summary of what features were added during the 0.25.x release and new stuff in 0.26.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#new-features-during-the-025x-series","title":"New Features during the 0.25.x Series","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#debian-bullseye-support","title":"Debian Bullseye Support","text":"

    #4742

    Dokku has supported both Debian and Ubuntu for quite a while - our packages are universal and actually can be installed all the way back to Ubuntu 14.04, even though we no longer officially support it. Bullseye came in a few days after the 0.25.0 release, so adding support for it made total sense.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#faster-herokuish-builds-when-injecting-environment-variables","title":"Faster Herokuish builds when injecting environment variables","text":"

    #4741

    Previously, herokuish buildpack builds would use intermediate containers for injecting the initial environment variables during the build process. This was actually quite slow - a container is created, started, some command is run, and then we create the image from that container - and also sometimes resulted in leftover containers if a build failed.

    We now initialize app environment variables via a special Dockerfile, which skips the intermediate container completely. Not only is this a bit faster, but we also no longer need to cleanup after the intermediate container.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#vscode-remote-container-support","title":"VSCode Remote Container Support","text":"

    #4785 #4791 #4800 #4814

    For anyone doing Dokku development, being able to simulate the entire environment is :major: for productivity. Setting up a virtual machine can be:

    We\u2019ve since added more complete support for developing in VSCode\u2019s Remote Container environment. In the future, supporting Azure and GitHub dev containers is in the cards, but this should enable most developers to more smoothly develop, test, and contribute to Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#schedule-process-types-in-parallel","title":"Schedule Process Types in Parallel","text":"

    Note

    This functionality was graciously sponsored by Rechat, a company doing remarkable efforts to help simplify and elevate how Real Estate Agents and Brokers operate.

    #4829

    Previously, we would deploy each container process type one at a time. For most users, this was not a huge deal, but users deploying apps with 10+ apps would encounter multi-minute deploys.

    As of 0.25.5, users can set the parallelism on processed process types. The web process is now always deployed first, while all other processes will deployed after the fact. The following command will set parallelism to 4 (default: 1) for non-web processes:

    dokku scheduler-docker-local:set $APP parallel-schedule-count 4\n
    This only applies to the list of process types scheduled at once, not individual containers within a process type.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#changes-in-026x","title":"Changes in 0.26.x","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#removal-of-deprecated-tags-and-tar-plugins","title":"Removal of deprecated tags and tar plugins","text":"

    #4858 #4859

    These two plugins were previously deprecated in 0.24.x in favor of git:from-image and git:from-archive, respectively. Rather than keep an unmaintained, buggy implementation of deployment, we\u2019ve completely removed these two plugins. Users should switch to the recommended methods of deployment, which are much more flexible and better integrate with Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#faster-restarts-and-single-process-restarts","title":"Faster restarts and single-process restarts","text":"

    #4765

    Previously a restart would result in a complete rebuild of an application. With this change, restarts will now only rebuild when the image does not exist, and otherwise simply restart processes with the built image.

    In addition, a user may restart just a single process type. While not common, this can be used as a proxy for killing processes that consume memory, while not requiring a full app rebuild or restart.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#increase-parallelism-for-containers-within-specific-process-types","title":"Increase parallelism for containers within specific process types","text":"

    #4860

    As a followup to #4829, apps deployed via the docker-local scheduler can now perform parallel scheduling for specific process types. The default configuration follows the existing behavior, while engineers that need extra parallelism on a per-process type basis can configure it via the app.json file:

    {\n    \u201cformation\u201d: {\n        \u201cweb\u201d: {\n            \u201cmax_parallel\u201d: 3\n        }\n    }\n}\n

    Parallelism defaults to 1 (previous behavior) but can be increased as needed.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#scheduler-management-plugin","title":"Scheduler Management Plugin","text":"

    #4857

    As we move towards a 1.0 release, Dokku\u2019s internal configuration that can be modified via environment variables is being moved into plugin-specific configuration settings. Setting a scheduler is one of them, and 0.26.0 will migrate the DOKKU_SCHEDULER environment variable to a scheduler plugin setting. Going forward, should set the scheduler via scheduler:set [app|\u2014global] selected call.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#raspberry-pi-support","title":"Raspberry PI Support","text":"

    #4885 #4887 #4888 #4889

    Dokku has always lived in the realm of self-hosting, but it was always x86-based. This completely precluded ARM users from using Dokku, which wasn\u2019t great for those who fully self-hosted, servers included.

    In the first few releases of 0.26.x, we\u2019ve added armhf architecture support, allowing those using Raspbian to install Dokku. Adding support for other ARM architectures should be rather trivial in the future (provided there is Golang support).

    Some notes:

    While there are some limitations, the general Dokku experience works quite well on ARM, and hopefully opens up experimentation to the general development community.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.26.0 migration guide for more information on upgrading to 0.26.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    We'll have more information in the coming week, but Dokku Pro will be provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 9 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/","title":"Dokku Release 0.28.0","text":"

    It's been a little over two weeks since our 0.28.x release landed. Here is a summary of what new stuff is in 0.28.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#changes-in-026x","title":"Changes in 0.26.x","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#removal-of-deprecated-tags-and-tar-plugins","title":"Removal of deprecated tags and tar plugins","text":"

    #4858 #4859

    These two plugins were previously deprecated in 0.24.x in favor of git:from-image and git:from-archive, respectively. Rather than keep an unmaintained, buggy implementation of deployment, we\u2019ve completely removed these two plugins. Users should switch to the recommended methods of deployment, which are much more flexible and better integrate with Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#faster-restarts-and-single-process-restarts","title":"Faster restarts and single-process restarts","text":"

    #4765

    Previously a restart would result in a complete rebuild of an application. With this change, restarts will now only rebuild when the image does not exist, and otherwise simply restart processes with the built image.

    In addition, a user may restart just a single process type. While not common, this can be used as a proxy for killing processes that consume memory, while not requiring a full app rebuild or restart.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#increase-parallelism-for-containers-within-specific-process-types","title":"Increase parallelism for containers within specific process types","text":"

    #4860

    As a followup to #4829, apps deployed via the docker-local scheduler can now perform parallel scheduling for specific process types. The default configuration follows the existing behavior, while engineers that need extra parallelism on a per-process type basis can configure it via the app.json file:

    {\n    \u201cformation\u201d: {\n        \u201cweb\u201d: {\n            \u201cmax_parallel\u201d: 3\n        }\n    }\n}\n

    Parallelism defaults to 1 (previous behavior) but can be increased as needed.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#scheduler-management-plugin","title":"Scheduler Management Plugin","text":"

    #4857

    As we move towards a 1.0 release, Dokku\u2019s internal configuration that can be modified via environment variables is being moved into plugin-specific configuration settings. Setting a scheduler is one of them, and 0.26.0 will migrate the DOKKU_SCHEDULER environment variable to a scheduler plugin setting. Going forward, should set the scheduler via scheduler:set [app|\u2014global] selected call.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#raspberry-pi-support","title":"Raspberry PI Support","text":"

    #4885 #4887 #4888 #4889

    Dokku has always lived in the realm of self-hosting, but it was always x86-based. This completely precluded ARM users from using Dokku, which wasn\u2019t great for those who fully self-hosted, servers included.

    In the first few releases of 0.26.x, we\u2019ve added armhf architecture support, allowing those using Raspbian to install Dokku. Adding support for other ARM architectures should be rather trivial in the future (provided there is Golang support).

    Some notes:

    While there are some limitations, the general Dokku experience works quite well on ARM, and hopefully opens up experimentation to the general development community.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.28.0 migration guide for more information on upgrading to 0.28.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    We'll have more information in the coming week, but Dokku Pro will be provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 9 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/","title":"Dokku's Roaring 0.20s","text":"

    It's been a few months since the last release post, so we'll summarize whats been going on in Dokku Land in 2020.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#discussions","title":"Discussions","text":"

    Where should you get help? We've added Github Discussions support to the main project. Folks are encouraged to post questions and seek help from the community there. This will be a monitored channel, and is subject to the Code of Conduct.

    If you are seeking more \"live\" support, join the #dokku channel on the Gliderlabs Slack. A member of the core team - in addition to community members! - will attempt to help you given enough time and information.

    Users can continue posting to Stackoverflow or other locations, though those will not be actively monitored for issues.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#releases","title":"Releases","text":"","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#021x","title":"0.21.x","text":"

    We released quite a few major things in the 0.21.0 release:

    Other than the above, 0.21.0 was mostly a bugfix release. Hopefully it was to your liking.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#022x","title":"0.22.x","text":"

    The 0.22.x was a bit more expansive in the number of changes it introduced. There were a number of changes and deprecations, the most major of which were:

    What else showed up in 0.22.x?

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#cloud-native-buildpacks-support","title":"Cloud Native Buildpacks support","text":"

    Cloud Native Buildpacks are the future of Dokku's Buildpack support. We previously blogged about it, comparing it to our current Herokuish support. This new initiative is supported by a wide range of folks affiliated with the Cloud Native Computing Foundation, and we're hoping to see tighter integration with Dokku in the future.

    While it's still in development, this functionality is currently behind an app-specific environment variable and depends on the pack binary. To use it:

    # where $APP is your app name\ndokku config:set $APP DOKKU_CNB_EXPERIMENTAL=1\n\n# install pack: https://buildpacks.io/docs/tools/pack/\n# apt based installation in use here, but use what you are comfortable with\nsudo add-apt-repository ppa:cncf-buildpacks/pack-cli\nsudo apt-get update\nsudo apt-get install pack-cli\n

    Some future improvements:

    Definitely a space to watch.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#aggressive-container-cleanup","title":"Aggressive Container Cleanup","text":"

    Previous releases of Dokku would leave behind intermediate containers for debugging purposes. As Dokku has largely stabilized, these containers are no longer as necessary. The intermediate containers are commonly confused for containers that utilize server resources. Even worse, Docker will occasionally start these intermediate containers on reboot (Docker does not keep track of whether a container was manually stopped or not), causing actual performance issues for servers.

    In 0.22.x, we start deleting these intermediate containers at most 5 minutes after a deploy, and sometimes even sooner. We also cleanup images that may have been used during this process. While the cleanup time is not currently configurable, we hope that this change allows folks to feel better about resource utilization on more constrained servers.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#nginx-configuration-knobs","title":"Nginx Configuration Knobs","text":"

    While we attempt to ship with the best nginx configuration by default, folks may want to tune specific knobs to match their setup without needing to ship an nginx.conf.sigil that may become outdated. We've added an nginx:set command that can be used to set various nginx settings, and will continue to add more settings over time.

    Additionally, for installations that have a single nginx.conf.sigil that should be used amongst all apps by default, we've added the ability to set the location of the global defaults via a plugin trigger. This is exceptionally useful for platform creators that must inject some special configuration to integrate with their platform.

    Finally, if you wish to disable app-side nginx.conf.sigil extraction, we've added a tunable property for this via nginx:set (disable-custom-config). While this cannot currently be set globally or as a default, enterprising platform developers may create plugins that inject properties on app creation...

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#vector-based-log-shipping","title":"Vector-based Log Shipping","text":"

    This came late in the 0.22.x lifecycle (0.22.6/0.22.7), but was added to address the logging options issue (#2268). Vector is an open-source, lightweight and ultra-fast tool for building observability pipelines. Dokku integrates with it for shipping container logs for the docker-local scheduler. Users may configure log-shipping on a per-app or global basis, neither of which interfere with the dokku logs commands.

    Vector is based on the idea of inputs, transforms and sinks. Dokku will automatically inject the correct inputs for all Docker containers, and it is up to you to define a sink to which you can send container logs (globally or per-app). Dokku does not currently support customizing transforms, though this may come in a future release.

    Checkout the Vector Log Shipping docs for more usage information.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#golang-plugin-rewrites","title":"Golang Plugin Rewrites","text":"

    A few plugins have been rewritten in Golang:

    Generally speaking, plugins are rewritten when the complexity of writing future features outweighs keeping the plugin implemented in shell code. In particular, any plugins that perform one of the following tasks are good candidates for higher-level languages:

    While all of these have been performed one time or another in bash, the fact is that there are a ton of edge cases that have popped up over the years that make it super difficult to even reason about some of the code, whereas it is fairly easy for me to handle these within Golang (either with the standard library or something off-the-shelf).

    All that said, not all plugins will be rewritten in Golang - the git plugin is likely to stay as is - and some plugins may see hybrid rewrites as necessary, but this should hopefully give folks a bit of an idea as to why the Dokku codebase is not predominantly written in shell.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.22.0 migration guide for more information on upgrading to 0.22.0.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#future-development","title":"Future Development","text":"

    0.22.x was a feature-packed release, and we're not slowing down. 0.23.x is around the corner, and will include quite a few interesting features for folks. We'll save those notes for the next blog post :)

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/","title":"Dokku 0.27.x Wrapup","text":"

    Dokku version 0.27.0 was released a few months ago. This post covers the important changes that occurred throughout the lifetime of the 0.27.x series. A future post will cover the 0.28.0 release.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#os-and-architecture-support","title":"OS and Architecture Support","text":"

    Ubuntu Focal was added as a release target. We also added support for ARM (32-bit) and ARM64 architectures. Users on Raspberry Pis should be able to install the latest Dokku, regardless of OS or Architecture.

    Additionally, the Dokku docker image is now based on Focal :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#app-and-service-filtering","title":"App and service filtering","text":"

    It is now possible to filter apps and services via the user-auth-app and user-auth-service triggers. These can be implemented in custom plugins to constrain what a user has access to, and is in use within Dokku Pro for it's team-management system.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#fixes","title":"Fixes","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#app-domain-renames-are-scoped-to-global-domains","title":"App domain renames are scoped to global domains","text":"

    Previously, if you had an app named test with a domain of tester.com and renamed it to test-2, we would rename the domain to test-2er.com. We've now scoped this so app renames only impact domains associated with any global domains on the server.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#remove-bad-intermediate-containers","title":"Remove bad intermediate containers","text":"

    Due to how Dokku handles the build process, intermediate containers reuse the internal docker image name for an app. This means that it is sometimes possible to execute dokku run against an intermediate image.

    Dokku now properly removes intermediate images if the build fails.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#support-for-special-characters-in-docker-container-options","title":"Support for special characters in docker container options","text":"

    Dokku now supports using special characters, such as parenthesis, in container options. Here is an example:

    dokku docker-options:add node-js-app deploy '--label \"some.key=Host(\\`node-js-app.dokku.arketyped.net\\`)\"'\n

    Some characters should be escaped - and quoting matters! - but label-based proxy-implementations can now take full advantage of apps deployed via Dokku.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.27.0 migration guide for more information on upgrading to 0.27.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    Those were the major changes in 0.27.x. Our next post will cover 0.28.0!

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/","title":"Dokku 0.28.x Wrapup","text":"

    It's wrapup time! This post covers the important changes that occurred throughout the lifetime of the 0.28.x series.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#removals","title":"Removals","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#no-more-support-for-centos-7-debian-9-fedora-opensuse","title":"No more support for Centos 7, Debian 9, Fedora, OpenSuse","text":"

    With the maturation of our Docker-based deployment offering, we've removed official support for these other operating systems.

    Why would we do this? For Centos, Fedora, and OpenSuse, they were simply untested integrations that were half-baked into Dokku over the years. Worse, we only ever built a package for Centos, and never actually guaranteed support for the others.

    As far as Debian 9 is concerned, the OS reached end-of-life in July of 2022, and it only makes sense to drop support for something unsupported upstream.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#deprecations","title":"Deprecations","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#ubuntu-1804-is-deprecated","title":"Ubuntu 18.04 is deprecated","text":"

    Ubuntu 18.04 is now a deprecated installation target. The operating system will be considered EOL by Canonical in April 2023. Users are encouraged to upgrade to Ubuntu 22.04 or consider switching their installation method to the Docker-based installation method to avoid any disruption in usage.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#the-automatic-init-process-can-now-be-disabled","title":"The automatic init process can now be disabled","text":"

    This change allows projects using s6 overlay - in particular linxserver images - the ability to disable --init flag injection.

    Additionally, force-disable --init flag usage for all linuxserver images. Linuxserver images uses S6, and there are enough of them that this makes sense to autodetect on behalf of users.

    Users should be able to more easily deploy s6-based images, whether they are official Linuxserver ones or images they've built on their own :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#new-proxy-implementations","title":"New Proxy Implementations","text":"

    As we've grown, the nginx plugin has seen a few warts. Notably, it doesn't tightly integrate with Docker, which sometimes causes requests to either route to the wrong container or fail when the container changes IP address. Additionally, our Letsencrypt integration on top of it is a bit of a hack.

    As a result, we've decided to create official alternative proxy integrations to our existing nginx plugin. The first two are caddy and traefik, both of which boast healthy development processes and have great integrations with Docker-based deployment environments. In a future release, we also hope to add an official haproxy plugin, and may revisit our nginx integration as well.

    Please note that none of this means we're dropping support for our existing nginx integration. Users should feel comfortable depending on nginx, switching only as needed.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#an-official-caddy-proxy-implementation","title":"An official caddy proxy implementation","text":"

    This plugin uses a docker-compose based Caddy installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    One big change is that requests are routed as soon as the container is running and passing healthchecks.

    Checkout the official caddy integration documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#an-official-traefik-proxy-implementation","title":"An official traefik proxy implementation","text":"

    While Caddy is great, some folks may wish to pursue deeper, Traefik-based integration instead. Unlike Caddy, Traefik provides native integration with many schedulers, providing even deeper integration for your routing needs.

    This plugin uses a docker-compose based Traefik installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    Requests are routed as soon as the container is running and passing healthchecks.

    Checkout the official traefik integration documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#a-builder-for-lambda-functions","title":"A builder for lambda functions","text":"

    Dokku has always been a something of a generic workflow tool. Source code comes in, gets built into an artifact, and then can be scheduled.

    With 0.28.x, we've introduced a new builder-lambda plugin. This plugin emulates the lambda build process, generating both a runnable docker image and a tarball that is compatible with AWS Lambda. We hope to bring an AWS Lambda-compatible scheduler to Dokku in the near future.

    Checkout the official builder-lambda documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#add-support-for-devcontainers-on-arm64-instances","title":"Add support for devcontainers on ARM64 instances","text":"

    Lots of developers - including myself! - are moving to M1/M2 MacOS installations, and development of Dokku must continue. The 0.28.x series adds support for using VSCode Devcontainers on ARM64 instances, allowing development to continue unabated.

    Truthfully, this is somewhat selfish as my main driver had to change - RIP my Intel Mac - but hopefully others contributing to Dokku also benefit :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#fixes","title":"Fixes","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#set-corebaretrue-on-correct-repository-path","title":"Set core.bare=true on correct repository path","text":"

    When deploying a project via git:sync, it was possible to get into a state where your repo was no longer able to have git push executed against it. This change fixes that, so folks can initialize apps via git:sync for the first time and then git push afterwards.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#ignore-https-mappings-when-no-ssl-certificate-exists","title":"Ignore https mappings when no ssl certificate exists","text":"

    This fixes issues where users may somehow add an https mapping but are missing an ssl certificate, causing nginx to not load properly. We now ignore the mapping and warn users of the misconfiguration.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.28.0 migration guide for more information on upgrading to 0.28.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    Those were the major changes in 0.28.x. Our next post will cover 0.29.0!

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/","title":"Dokku Release 0.29.0","text":"

    The last minor release of the year is here! Here is a summary of what is new in 0.29.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#changes-in-029x","title":"Changes in 0.29.x","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#file-extraction-moved-from-image-to-repository","title":"File extraction moved from image to repository","text":"

    Previously, Dokku would build the app image - via whichever builder was specified - and then extract files from the built image. This allowed some level of customization of certain files - such as generating a Procfile or nginx.conf.sigil during the build process based on environment variables. However, the logic is a bit contrary to how we handle other files in mono-repo setups.

    With 0.29.x, we now extract files from the repository source code where possible. This allows our monorepo codebase handling to act the same everywhere and also speeds up app builds.

    Note

    The current notable exception to the new extraction process is the app.json file, which will be fixed in the next minor release.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#app-domains-are-now-setup-at-app-creation-time","title":"App domains are now setup at app creation time","text":"

    Previously, domains were attached to apps when proxy configuration was first generated. This caused issues when domains were referred to prior to the first app deploy. Dokku will now instead associate app domains on app creation, and users may later remove the domains as desired.

    One side effect of this is the refactor of how domains and app urls are referred to within Dokku. Please see the migration guide for more details how how this might impact your usage of Dokku.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#new-in-029x","title":"New in 0.29.x","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#run-subcommand-additions","title":"run subcommand additions","text":"

    We've added a few new commands to the built-in run plugin:

    We've also added JSON output support for the run:list command, making it easier to manipulate in a programmatic manner.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#initial-herokuish-support-on-arm-servers","title":"Initial herokuish support on ARM servers","text":"

    While Dokku has supported ARM/ARM64 servers for a while, Herokuish - the most common builder in use with Dokku - has not. While it is possible to make a buildpack ARM-compatible, the majority are not, and thus we blocked off the functionality to avoid causing issues for users.

    For more adventurous Dokku users, the herokuish builder can now be enabled on ARM/ARM64 servers (though it is not enabled by default). Individual buildpacks will still need to have support added for ARM/ARM64 platforms, but users are no longer artificially limited by Dokku to other builders.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.29.0 migration guide for more information on upgrading to 0.29.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 8 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/pro-release-1.1.0/","title":"Pro release 1.1.0","text":"

    The 1.1.0 release is the first substantive update to Dokku Pro, and it brings with it great changes around usability and functionality.

    Get your copy today

    Dokku Pro was released in late 2021 to early bird users willing to deal with a bit of pain in exchange for supporting the project and vision. While it technically worked, there were quite a few places for easy improvement, as well as obvious holes in the existing functionality. Dokku Pro 1.1.0 aims to fill some of those needs, laying the groundwork for future enhancements.

    Here are a few of the updates included in Dokku Pro 1.1.0.

    "},{"location":"2022/pro-release-1.1.0/#major-changes","title":"Major Changes","text":""},{"location":"2022/pro-release-1.1.0/#this-lovely-docs-site","title":"This lovely docs site","text":"

    We've added a more comprehensive documentation site for Dokku Pro. The documentation will continue to improve and will always reference the latest version of Dokku Pro (currently 1.1.0). Enjoy!

    "},{"location":"2022/pro-release-1.1.0/#requires-dokku-0270","title":"Requires Dokku 0.27.0","text":"

    The minimum Dokku version increase was made to ensure memory-scaling worked properly. Users of older version of Dokku may still have working installs, though memory scaling will not work correctly for the docker-local scheduler.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.1.0/#minimum-required-datastore-plugin-versions","title":"Minimum required datastore plugin versions","text":"

    As a reminder, it is also recommended to update all datastore plugins to ensure services are properly listed in the API and UI. In addition, the upgrades are necessary for support for deferred app rebuilds during service linking. Without them, service linking may time out.

    Here are the versions necessary for this release of Dokku Pro:

    Plugin Version clickhouse 0.13.3 couchdb 1.21.4 elasticsearch 1.20.3 graphite 1.18.2 mariadb 1.19.2 meilisearch 0.2.1 memcached 1.18.4 mongo 1.17.4 mysql 1.19.4 nats 1.19.3 omnisci 1.19.1 postgres 1.19.3 pushpin 0.9.1 rabbitmq 1.19.4 redis 1.19.2 rethinkdb 1.17.2 solr 1.19.4

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.1.0/#add-ability-to-link-an-app-to-a-service","title":"Add ability to link an app to a service","text":"

    Users are now able to link apps to services. This required a ton of changes to how datastores worked in the API, and the resulting refactor makes it much easier to add new datastores to Dokku Pro.

    To manage service links, go to the Settings section of a given app and use the Linked Services subsection.

    UI for managing service links"},{"location":"2022/pro-release-1.1.0/#refactor-datastore-and-service-apis-for-easier-expansion","title":"Refactor datastore and service apis for easier expansion","text":"

    In order to make service linking work, we required a few changes:

    Dokku Pro 1.1.0 brings a simplified /datastores and /services api. The former is used to interact with the datastore plugins as a whole - in the future, this may even include setting global datastore plugin properties. The /services endpoint now abstracts all instances of every datastore, bringing a single api endpoint for querying and interacting with all services installed on your Dokku server. This makes it much simpler to support a new datastore - now a 2-line change - versus the previous method of generating various files that still needed work to plug into the api model layer.

    These APIs are now considered stable for external use. Enjoy!

    "},{"location":"2022/pro-release-1.1.0/#implement-resource-scaling-ui","title":"Implement resource scaling ui","text":"

    The initial release of Dokku Pro included process count scaling, but offered nothing for container resources. New in 1.1.0, we added the ability to set memory reservations.

    Memory scaling

    For this rough release, we've opted to avoid limits - so that containers can burst on resource utilization - and have omitted CPU - as this is typically bursty on single-instance Dokku installations. We'll be working on the UI in future releases, and hope to include both memory and CPU for limits and reservations in a way that makes sense for our users.

    See this tweet thread for more details on how... interesting this functionality ended up.

    "},{"location":"2022/pro-release-1.1.0/#add-swagger-support","title":"Add swagger support","text":"

    An interactive Swagger UI for Dokku Pro is now available at the /swagger endpoint. Users can also access the OpenAPI 3.0.1 spec at /swagger/openapi.yml.

    Integrated Swagger UI"},{"location":"2022/pro-release-1.1.0/#add-ability-to-set-the-scheduler-on-a-per-app-basis","title":"Add ability to set the scheduler on a per-app basis","text":"

    We've added the ability to set an app scheduler on a per-app basis. This automatically picks up the following schedulers (if installed) and displays them for selection:

    Selection a non-standard scheduler"},{"location":"2022/pro-release-1.1.0/#minor-changes","title":"Minor Changes","text":""},{"location":"2022/pro-release-1.1.0/#allow-customizing-the-network-dokku-pro-listens-on","title":"Allow customizing the network dokku-pro listens on","text":"

    If you are running Dokku Pro on a local network that doesn't have IPv6 support, you can now set the SERVER_NETWORK configuration variable to tcp4 to listen only on IPv4.

    "},{"location":"2022/pro-release-1.1.0/#set-higher-default-write-timeout-to-allow-for-slow-service-creation-calls-to-complete","title":"Set higher default write timeout to allow for slow service creation calls to complete","text":"

    The default server read and write timeouts were too low for certain tasks - notably datastore creation and destruction - to complete in time, resulting in UI errors. These are now configurable via SERVER_READ_TIMEOUT and SERVER_WRITE_TIMEOUT, and also have higher default values. Folks on slower servers should see significant improvement in their overall user experience.

    "},{"location":"2022/pro-release-1.1.0/#add-cli-command-for-outputting-current-dokku-pro-settings","title":"Add cli command for outputting current dokku-pro settings","text":"

    One annoying issue when debugging an installation is ensuring all the configuration variables are set properly. Users can now run dokku-pro config to show a user-friendly version of the current server config. This can be used to verify that the Dokku Pro license and other configuration options are as you expect.

    "},{"location":"2022/pro-release-1.1.0/#ui-changes","title":"UI Changes","text":""},{"location":"2022/pro-release-1.1.0/#always-use-correct-icon-size-for-app-status","title":"Always use correct icon size for app status","text":"

    The app status icon was sometimes too large. While big head mode is cool, its not so much in a UI. We now use the correct image size.

    "},{"location":"2022/pro-release-1.1.0/#fix-issue-in-ui-when-saving-a-domain-for-an-app","title":"Fix issue in ui when saving a domain for an app","text":"

    Apps with no domains had issues saving an initial domain without using the CLI. Since one of the goals of Dokku Pro is to supply a web UI, this seems a bit backwards. You can now properly set domains for new apps!

    "},{"location":"2022/pro-release-1.1.0/#correct-process-type-name-in-the-scaling-ui","title":"Correct process type name in the scaling UI","text":"

    The process scaling ui showed the app name instead of the process type. This made no sense and was confusing for users with multiple process types.

    "},{"location":"2022/pro-release-1.1.0/#make-the-envdomains-settings-pages-span-the-entire-page","title":"Make the env/domains settings pages span the entire page","text":"

    There was a minor change to the environment variable and domain setting pages that made better use of the screen real estate.

    "},{"location":"2022/pro-release-1.1.0/#api-changes","title":"API Changes","text":""},{"location":"2022/pro-release-1.1.0/#add-meilisearch-datastore-plugin","title":"Add meilisearch datastore plugin","text":"

    Taking advantage of our new datastore plumbing, we added the Meilisearch plugin to Dokku Pro.

    "},{"location":"2022/pro-release-1.1.0/#add-better-error-messaging-when-validating-api-entities-from-composite-keys","title":"Add better error messaging when validating api entities from composite keys","text":"

    When interacting with entities that have composite primary keys - domains, environment variables, formations - users would get somewhat opaque error messages. These have been updated to include more detail.

    "},{"location":"2022/pro-release-1.1.0/#fix-access-to-service-relationships-in-the-api","title":"Fix access to service relationships in the api","text":"

    Services now come back as properly associated with apps, making many of the normal json-api relationship endpoints work.

    "},{"location":"2022/pro-release-1.1.0/#dokku-pro-pricing","title":"Dokku Pro Pricing","text":"

    Now that there is a new release of Dokku Pro, the early bird pricing will increase. This was previously mentioned in various Dokku Pro announcements, but the price will continue to increase by various amounts until the product settles.

    Please bear in mind that this is a lifetime license, and users are entitled to all upgrades of Dokku Pro as long as they are made. Folks wishing to support continued development of the project are encouraged to purchase today before the price is increased.

    Get your copy today

    "},{"location":"2022/pro-release-1.1.0/#coming-up-next","title":"Coming up next?","text":"

    The next milestone will continue to have many minor additions, with some effort made on the following additions:

    As always, the roadmap is always subject to change, pending time constraints but mostly feature requests by those who have purchased Dokku Pro. Have a feature request or bug complaint? Feel free to file it in the issue tracker here.

    Thanks everyone for there support during this endeavor, and I hope you all enjoy this release of Dokku Pro!

    "},{"location":"2022/pro-release-1.2.0/","title":"Pro release 1.2.0","text":"

    The 1.2.0 release introduces team-based access control and many internal refactors aimed at easing future development of the product.

    Get your copy today

    Dokku has traditionally been a single-tenant PaaS solution, where all users had access to all functionality on the server. While there were community plugins that tackled authentication, each implementation had it's rough edges due to interfaces in Dokku itself. Dokku Pro 1.2.0 polishes those edges while introducing a flexible permission system for organizations that need it.

    Here are a few of the updates included in Dokku Pro 1.2.0.

    "},{"location":"2022/pro-release-1.2.0/#major-changes","title":"Major Changes","text":""},{"location":"2022/pro-release-1.2.0/#requires-dokku-0278","title":"Requires Dokku 0.27.8+","text":"

    Warning

    Dokku Pro 1.2+ will refuse to start if the minimum Dokku version is not installed.

    The minimum Dokku version increase was made to support new functionality in Dokku Pro. The previous 1.1.0 version required at least 0.27.0, so hopefully this upgrade does not cause too many issues for folks.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#minimum-required-service-plugin-versions","title":"Minimum required service plugin versions","text":"

    Warning

    Dokku Pro 1.2+ will refuse to start if an installed plugin is not at the minimum supported version.

    As a reminder, it is also recommended to update all service plugins to ensure services are properly listed in the API and UI. In addition, the upgrades are necessary for support for deferred app rebuilds during service linking. Without them, service linking may time out.

    Certain new functionality in Dokku Pro required changes to the service plugins.

    Here are the versions necessary for this release of Dokku Pro:

    Plugin Version clickhouse 0.17.0 couchdb 1.25.0 elasticsearch 1.24.0 graphite 1.22.0 mariadb 1.24.0 meilisearch 0.6.0 memcached 1.22.0 mongo 1.21.0 mysql 1.23.0 nats 1.24.0 omnisci 1.23.0 postgres 1.24.0 pushpin 0.14.0 rabbitmq 1.24.0 redis 1.24.0 rethinkdb 1.21.0 solr 1.24.0 typesense 1.5.0

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#new-apis-for-community-plugins","title":"New APIs for community plugins","text":"

    Two plugins were added to Dokku Pro's HTTP API. API Support for Dokku features generally comes first, while later releases will include changes to the Web UI to include these additions.

    "},{"location":"2022/pro-release-1.2.0/#api-support-for-the-community-http-auth-plugin","title":"API support for the community HTTP Auth Plugin","text":"

    Authentication comes in many forms, and while most apps have this built-in, simpler, pre-packaged applications may not. Dokku Pro introduces support for the community http-auth plugin, with full API support for managing both user-based and IP-based access controls. This comes with documentation in our included Swagger UI.

    A future release of Dokku Pro will include a section in the UI for managing network components for apps, including HTTP Auth support.

    "},{"location":"2022/pro-release-1.2.0/#api-support-for-the-community-http-auth-plugin_1","title":"API support for the community HTTP Auth Plugin","text":"

    In addition to authentication requirements, it may be necessary to enable or disable all access to your application. The community maintenance plugin provides the ability to do just that.

    In this release, we've added the ability to enable or disable maintenance mode via API, fully-documented within our included Swagger UI. A future release of Dokku Pro will include a section in the UI for managing network components for apps, including setting apps in maintenance mode.

    "},{"location":"2022/pro-release-1.2.0/#add-ability-to-set-the-builder-on-a-per-app-basis","title":"Add ability to set the builder on a per-app basis","text":"

    We've added the ability to set an app builder on a per-app basis. This automatically picks up the following builders (if installed) and displays them for selection:

    Selection a non-standard builder

    It is also possible to set a custom build directory in the same UI.

    Selection a non-standard builder

    Both of these include API access, documented in our included Swagger UI.

    "},{"location":"2022/pro-release-1.2.0/#team-management","title":"Team Management","text":"

    Access control is a complex topic, and one Dokku has traditionally shied away from. Dokku does not have a traditional user model, and it associates a simple name to each ssh-key that a user uses to interact with the CLI over SSH. Until recently, the only way to limit access was by installing the community dokku-acl plugin and hoping it's rigid model for checking permissions aligned with how you wanted to expose server access.

    With Dokku Pro 1.2.0, there is now a flexible team-based model for access control. System administrators can continue to access everything, but may create teams with permissions against particular apps, services, and commands. Owners - such as team leads or project managers - can be assigned to teams, delegating access control for those teams to the folks closest to what those teams represent. And finally, team members can perform the commands allowed by their team permissions against the apps and services those teams control, and nothing more.

    The development of this feature required changes across the Dokku ecosystem. New triggers were exposed in both service plugins as well as Dokku itself to manage filtering of apps and services, while some plugins had to be updated in order to respect the updated command system. Dokku Pro itself had several changes to the permissioning system as it was designed and tested in real world settings. While the initial intent was to release Dokku Pro much more often, the work behind team management hopefully makes the wait worth it.

    The initial release of team management is available via CLI commands. This decision was made in order to release Dokku Pro sooner. A future release of Dokku Pro will include API support for team management as well as Web UI integration for managing teams.

    Checkout the team management documentation for more information on how team-based access control works.

    "},{"location":"2022/pro-release-1.2.0/#minor-changes","title":"Minor Changes","text":"

    Some of the more minor changes were made to make development of Dokku Pro itself much more pleasant. Rather than having a \"miscellaneous bug fixes and improvements\" section as you'd see in many other public product release notes, we'll outline them below.

    "},{"location":"2022/pro-release-1.2.0/#updated-dependencies","title":"Updated Dependencies","text":"

    Dokku Pro uses a ton of code itself. We've started the efforts to get the server-side code up to date in an automatic fashion, and are ramping up efforts to modernize the Web UI as well.

    "},{"location":"2022/pro-release-1.2.0/#filtering-apps-in-dokku-pro","title":"Filtering apps in Dokku Pro","text":"

    For some use-cases, it may be necessary to hide some apps from the Web UI and API. In the case of Dokku's own installation of Dokku Pro, there are some testing apps that have no value other than being placeholders for requests, and thus are noise in the UI.

    It is now possible to filter such apps from being accessible via Dokku Pro's interface (they will still be available via CLI using normal dokku commands). An APPS_FILTER environment variable can be set in the Dokku config with a comma-delimited list of apps to hide. These apps will be hidden from API responses and the Web UI as a result.

    Checkout the configuration documentation for more information on this new setting.

    "},{"location":"2022/pro-release-1.2.0/#ability-to-override-the-default-root-username","title":"Ability to override the default root username","text":"

    While the password for authentication is configurable, the root username was not. An ROOT_USERNAME can be set in the Dokku config to override the default root username. You can now login as the lollipop user if desired.

    Checkout the configuration documentation for more information on this new setting.

    "},{"location":"2022/pro-release-1.2.0/#typesense-service-support","title":"Typesense service support","text":"

    Support for the new typesense plugin has been added to services in Dokku. Users can expect the same functionality they would from other services in Dokku, including complete support in our API, Swagger UI documentation, and exposure in the Web UI.

    New services will be added to future Dokku Pro releases as they are made available.

    "},{"location":"2022/pro-release-1.2.0/#version-checking-for-server-commands","title":"Version checking for server commands","text":"

    As mentioned above, we now check for specific versions of Dokku and installed plugins on start of the Dokku Pro server. Users wishing to use supported plugins that do not have at least the minimum version specified will have Dokku Pro fail to boot with an error message detailing the problem.

    Please be sure to keep up to date with the latest and greatest versions of Dokku and any plugins you use.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#enhanced-output-for-the-config-command","title":"Enhanced output for the config command","text":"

    When running the dokku-pro config command, we previously hardcoded how certain config was output. This has been refactored in such a way that we no longer need to update the config command when adding new configuration properties.

    "},{"location":"2022/pro-release-1.2.0/#fix-log-formatting","title":"Fix log formatting","text":"

    Log output was a bit broken for the help and version commands, and elsewhere. Dokku Pro now will only log in JSON format when there is no TTY - for example, when running under systemd - and will have human-readable output otherwise

    Additionally, we now use a single logging mechanism across the codebase, ensuring most - if not all - logs are in the proper format, regardless of where the log call is created.

    "},{"location":"2022/pro-release-1.2.0/#ignoring-compiled-assets-during-project-search","title":"Ignoring compiled assets during project search","text":"

    This was actually a fairly painful issue, workflow-wise. Searching for instances of code during refactoring was made painful due to including compiled assets, binary files, and external dependencies. These are now ignored so the editor does not lock up when searching for a random bit of javascript :)

    "},{"location":"2022/pro-release-1.2.0/#standardized-code-initialization","title":"Standardized code initialization","text":"

    Previously, Dokku Pro would set up certain checks and load config on-the-fly. This led to race conditions in certain cases, and was messier to understand. All initialization code has now been placed in a central location that is easy to understand when first diving into the code.

    "},{"location":"2022/pro-release-1.2.0/#dokku-pro-pricing","title":"Dokku Pro Pricing","text":"

    With a new release comes a price increase. Although it was mentioned in the 1.1.0 release post, we previously avoided a price increase to give folks more time to consider supporting Dokku Pro development at a lower price point. With the new functionality, we believe it is time to start the increases. Dokku Pro's price will continue to increase over time by various amounts until the product settles to a more \"feature-complete\" state.

    Please bear in mind that this is a lifetime license, and users are entitled to all upgrades of Dokku Pro as long as they are made. Folks wishing to support continued development of the project are encouraged to purchase today before the price is increased.

    Get your copy today

    "},{"location":"2022/pro-release-1.2.0/#coming-up-next","title":"Coming up next?","text":"

    Here is what we'll be working towards over the next few releases

    As always, the roadmap is always subject to change, pending time constraints but mostly feature requests by those who have purchased Dokku Pro. Have a feature request or bug complaint? Feel free to file it in the issue tracker here.

    Thanks everyone for there support during this endeavor, and I hope you all enjoy this release of Dokku Pro!

    "},{"location":"2023/dokku-0.30.0/","title":"Dokku Release 0.30.0","text":"

    The first minor release of the year is here! Here is a summary of what is new in 0.30.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#removals-in-030x","title":"Removals in 0.30.x","text":"

    The following functionality has long been deprecated and is now removed:

    We also removed a ton of deprecated commands and functions across dokku in #5659.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#changes-in-030x","title":"Changes in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#eol-of-ubuntu-1804-support","title":"EOL of Ubuntu 18.04 support","text":"

    With upstream dropping LTS support, Ubuntu 18.04 support in Dokku is EOL. Users are heavily encouraged to upgrade their operating systems to Ubuntu 20.04 or Ubuntu 22.04, either via an upgrade or fresh install. The next release of Dokku will stop releasing for Ubuntu 18.04 and packages will be removed in the future.

    Please note that while our existing packages may continue to run on Ubuntu 18.04, issues for those running on 18.04 may be summarily closed.

    Finally, Herokuish will also shortly drop Ubuntu 18.04 releases. Users are heavily encouraged to upgrade their apps to newer stacks, as those apps may fail to build for a variety of reasons.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#appjson-extraction-moved-from-image-to-repository","title":"app.json extraction moved from image to repository","text":"

    In 0.29.x, we moved file extraction for various supporting files from the built image to the app source. This change now also applies to app.json. This was done in order to standardize how mono-repo codebases were built.

    With 0.30.x, we now extract app.json from the repository source code where possible. This allows our monorepo codebase handling to act the same everywhere and also speeds up app builds.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#new-in-030x","title":"New in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#an-official-haproxy-proxy-implementation","title":"An official haproxy proxy implementation","text":"

    This plugin uses a docker-compose based Haproxy installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    Big thanks to @byjg for their work on EasyHAProxy

    Checkout the official haproxy integration documentation here!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#simplified-image-deployment-via-gitload-image","title":"Simplified image deployment via git:load-image","text":"

    Similar to git:load-image - and using the same internal infrastructure to manage history - there is a new git:load-image command. This new command supports deploying the output of docker image save $IMAGE_NAME on stdin, keeping git history with every deploy.

    The git:load-image command is meant to be used in cases where the deployment model is to deploy from a built docker image in CI. This is useful when users do not have an intermediate docker registry available from which they can deploy.

    See the git documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#interacting-with-multiple-dokku-remotes-via-the-official-client","title":"Interacting with multiple dokku remotes via the official client","text":"

    In some cases, users may deploy a given repository to multiple Dokku apps. This is especially useful when deploying to pre-production environments or using review apps. The official client now supports a series of remote subcommands that allow users to manage remotes for a local repository.

    See the remote client documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#nginx-proxy-rebuilds-early-to-avoid-downtime","title":"Nginx proxy rebuilds early to avoid downtime","text":"

    In a previous release, we moved the web process to be deployed first. This allowed folks to quickly see errors on their mainline process, vs seeing those near the end. The end result, however, made it so that apps with large numbers of process types had downtime as the old web containers were removed after a minute if the app also used nginx as it's proxy layer. Users of other proxy implementations - such as Caddy, Haproxy, and Traefik - are not affected by this bug.

    We now trigger an early rebuild of the nginx config for users utilizing the nginx proxy implementation. Concerned users should switch to other proxy implementations to be completely unaffected by this change.

    Note that a future release of Dokku will also provide an optional nginx-proxy layer based on labels similar to our other proxy implementations. This will avoid long-standing downtime issues and hopefully allow us to be more flexible in how applications can be proxied. See the nginx-docker-proxy project for more details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#avoid-reinstalling-plugins-in-the-provided-dokku-docker-image","title":"Avoid reinstalling plugins in the provided Dokku docker image","text":"

    We now no longer attempt to reinstall plugins that already exist. This fixes issues for users that specify plugins via a plugin-list versus installing directly to the docker image via a custom Dockerfile.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#fix-pack-entrypoint-support","title":"Fix pack entrypoint support","text":"

    A recent change in CNB's pack utility changed how processes were launched, causing any process to fail to start. We now specify a custom entrypoint to fix this issue. Users of CNB can get back to building their apps!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.30.0 migration guide for more information on upgrading to 0.30.0.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 7 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/","title":"Dokku Release 0.31.0","text":"

    The second release of the year is here! Here is a summary of what is new in 0.31.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#deprecations","title":"Deprecations","text":"

    To start, there are a few features that are now deprecated in Dokku.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#arm-not-arm64-support-is-deprecated","title":"ARM (not ARM64!) support is deprecated","text":"

    Our build process around ARM is fairly flaky - breaking CI more often than not - and the resulting docker image/debian packages are not actually tested. As a result, we're going to remove support for the platform in the next release, and recommend users upgrade their operating systems to ARM64 where possible.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#deprecation-of-the-checks-file","title":"Deprecation of the CHECKS file","text":"

    This file is now deprecated in favor of the new healthchecks functionality in app.json - more on that later - and users should begin migrating today. The docker-container-healthchecker tool can be used to convert a CHECKS file into the correct format for app.json usage. We expect to remove CHECKS support in a future release (likely 0.32.x).

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#proxyports-commands-are-deprecated","title":"proxy:ports-* commands are deprecated","text":"

    The proxy:ports-* commands are deprecated in favor of the new ports plugin - more on that later - users should adjust their workflows appropriately. The deprecation is occuring it was quite common for users to set port mappings incorrectly via proxy:set, thus breaking routing. Rather than keep the old commands around, we're going to nix it completely.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#changes-in-031x","title":"Changes in 0.31.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#heroku-22-is-the-new-default","title":"heroku-22 is the new default","text":"

    Dokku now tracks Ubuntu 22.04 for it's default builders. What does this mean?

    Users can still switch their base images via the command appropriate for their builder :)

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#herokuish-builds-now-use-volumes-for-cache","title":"Herokuish builds now use volumes for cache","text":"

    Previously, Herokuish builds would mount a directory on disk for build-time file caching. This worked mostly fine, but was an issue for a few reasons:

    Dokku now uses a docker volume for herokuish build cache - similar to how Cloud Native Buildpacks treat cache - which greatly simplifies cache management.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#new-in-030x","title":"New in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#an-official-openresty-proxy-implementation","title":"An official openresty proxy implementation","text":"

    This plugin uses a docker-compose based OpenResty installation in conjunction with injected container labels to route requests. It supports all properties supported by the nginx plugin, and includes built-in Letsencrypt support. Over time, we intend to make further improvements to this plugin and place the nginx plugin in a general maintenance mode. Users are encouraged to try out the OpenResty plugin to see if it meets their needs.

    Big thanks to OrcaScan for sponsoring the work on OpenResty!

    Checkout the official openresty integration documentation here.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#improved-healthchecking-support-via-appjson","title":"Improved healthchecking support via app.json","text":"

    The pre-existing healthcheck support in Dokku was fairly limited:

    All of these - and more - are solved by the new healthchecks support in the app.json file. Users can now specify one or more customized uptime checks, arbitrary command checks, as well as http checks (with more functionality!) for any process type.

    {\n  \"healthchecks\": {\n    \"web\": [\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"web check\",\n            \"description\": \"Checking if the app responds to the /health/ready endpoint\",\n            \"path\":        \"/health/ready\",\n            \"attempts\": 3\n        }\n    ],\n    \"worker\": [\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"uptime check\",\n            \"description\": \"Checking if the container is up for at least 10 seconds\",\n            \"uptime\":      10\n        },\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"command check\",\n            \"description\": \"Checking if a command in the container runs as expected\",\n            \"timeout\":     5,\n            \"attempts\":    5,\n            \"wait\":        10,\n            \"command\":     [\"/app/script.sh\"]\n        }\n    ]\n}\n

    Note

    Support for individual healthcheck properties is provided by individual schedulers, and not guaranteed to work the same across all schedulers. In particular, only the docker-local scheduler supports content checks for http requests.

    Dokku will convert all CHECKS files into the app.json format until support for that file format is removed, and users can use the docker-container-healthchecker tool to migrate to the new format.

    While we only support startup checks - checks that happen during container start at deploy time - in the future, Dokku will also support readiness and liveness checks in the future for it's docker-local scheduler.

    See the zero downtime deploy checks documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#dokku-cron-improvements","title":"Dokku Cron Improvements","text":"

    For the docker-local scheduler, the crontab generation has been sped up tremendously. Deploys on installations with many apps should be much quicker as cron tasks for each app are generated in parallel vs serially as had been the case.

    The cron:list command now has json output via the --format json option. This can help those integrating Dokku with other systems - such as Ansible modules.

    Finally, cron tasks can now be executed on the fly via the cron:run command. This takes a cron-id - retrievable from the cron:list command - and happens inline by default. They can also be invoked in a detached manner, allowing cron tasks to be run by dispatch.

    See the cron documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#environment-variables-are-available-for-use-with-dockerfile-based-builds","title":"Environment variables are available for use with Dockerfile-based builds","text":"

    Previously, a user wanting to use an environment variable during a build would have to specify the environment variable twice - once for run-time via config:set and once for build-time via docker-options:add. This was error prone as it was easy to fat finger a value, allowed for configuration drift, and made it more annoying to paste the output of dokku report for an app.

    Dokku now automatically exports all environment variables during Dockerfile build. Users can simply specify --build-arg SOME_ENV_VAR docker option to pull in the desired environment variable.

    See the dockerfile builder documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#multi-network-apps","title":"Multi-network apps","text":"

    Dokku has long had support for attaching apps to networks at different phases of an app lifecycle, but could only ever use a single network for each phase. This works well enough for simple architectures, but folks wanting more isolation between applications and datastores might want to place each in a different network and then join them as desired for inter-service communication.

    Dokku now supports specifying multiple, comma-separated networks at each phase. Users can enjoy network isolation support and more easily deploy advanced topologies with the docker-local scheduler, allowing them to mimic what might be the case in production.

    See the network documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#more-robust-port-handling-via-the-new-ports-plugin","title":"More robust port handling via the new ports plugin","text":"

    Dokku's port management has long been confusing:

    Dokku 0.31.x introduces a new ports plugin, reducing a ton of complexity around how port mappings are managed. The new plugin centralizes a lot of the port management code, resulting in a removal of a few port-related network triggers, some environment variables, and more.

    Additionally, Dokku now has \"detected\" port mappings that are fetched on a per-build basis. Users can override the port mapping as necessary, and Dokku will respect any overrides - or allow you to go back to the detected defaults! This makes it easy to ignore ports that are EXPOSEd in a Dockerfile or even use an alternate mapping for buildpack deploys.

    The new ports plugin fixes several long-standing issues in port management in Dokku, and hopefully simplifies port interactions for all of our users.

    See the port management documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#server-restarts-do-not-start-all-proxy-implementations","title":"Server restarts do not start all proxy implementations","text":"

    Dokku previously started a container for each proxy implementation, even when not in use. These are now properly tracked, and users will not see Dokku start the containers unless the user has explicitely run the :start subcommand.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#the-source-image-git-property-is-now-cleared-when-changing-deployment-methods","title":"The source-image git property is now cleared when changing deployment methods","text":"

    Previously, this property was left alone, resulting in Dokku not respecting the new source for extracting files for use in the deploy (such as app.json). Dokku will now properly handle this when the deployment method changes (such as when going from image-based to git push), greatly simplifying the process for our users who are experimenting with Dokku.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#traefik-integration-now-runs-correctly-when-running-on-arm64","title":"Traefik integration now runs correctly when running on ARM64","text":"

    Previously, users on ARM64 machines would not be able to enable traefik's letsencrypt integration due to a docker bug in file mounting. This is now fixed across all platforms - simply run traefik:stop and traefik:start.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.31.0 migration guide for more information on upgrading to 0.31.0.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#future-plans","title":"Future Plans","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#short-term-project-re-prioritization","title":"Short-term project re-prioritization","text":"

    With the release of Dokku 0.31.0, we've fixed a number of long-standing issues while also implementing a ton of great new features. While development isn't stopping, now is the time to refocus the project a bit for a few reasons:

    With all of the above in mind, the next few months will be spent on enhancing Dokku Pro, implementing long-desired functionality in the official plugins, burning through 1.0 blockers, and bringing the Kubernetes and Nomad scheduler plugins to parity with the built-in docker-local scheduler.

    Is Dokku going away? No. Development will continue unabated, just in other parts of the project. Other than Dokku Pro, no features will be placed behind any paywall, nor will features be removed from the project for any reason. Users can continue to know that Dokku will stay open source, providing a great base for busy developers to get their projects deployed so they can concentrate on building great products.

    We'll still be making releases over the coming months, albeit smaller ones that are more manageable in size. Hopefully the next Dokku release comes out in a month, and not 6 months!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 7 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]}]} \ No newline at end of file +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"2016/resource-management/","title":"Resource Management in Dokku","text":"

    Every so often, user's ask if it's possible to use Dokku as the basis of a system where each user in Dokku would have access to only their applications. Because of various reasons, this isn't possible out of the box, though it's certainly within the realm of possibility.

    There are two requirements for such a system, one of which we'll cover here.

    Tip

    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.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#resource-management","title":"Resource Management","text":"

    A common issue you may come up against is how to limit resource usage for different applications. One user's use of memory should not cause OOM issues in another application. Similarly, you would not want a particular application to hog the network bandwidth unfairly, or saturate disk I/O.

    These are not new problems to containers, multiple users on a system, or Dokku. These same issues also occur when deploying services directly on a server, or even running applications on your computer. Remember the last time your torrenting application used up all your network and you couldn't load a web page?

    It's also a solved problem. Applications that tend to use more bandwidth end up implementing quality of service algorithms to ensure your system runs smooth, allow users access to settings which they can modify to crank up/down resource usage, or some combination of the two. Dokku is no different.

    In Dokku's case, we normally provide users with high-level porcelain to handle the low-level plumbing. This usually comes in the form of plugins (porcelain) which orchestrates docker calls (plumbing). However, we move slowly from the plumbing towards porcelain as we judge just what the requirements are and how to best expose a ui around the given problem.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#persistent-storage","title":"Persistent Storage","text":"

    Take for instance the persistent storage. Dokku has long had plugin hooks, and very specifically implemented the docker-args plugin trigger way back in the 0.2.0 era. Gradually that evolved into the current docker-args-PHASE triggers, with the following phases:

    We discovered that while providing plugin triggers is great for tinkerers, it wasn't exactly the nicest way to configure docker options. Many users ended up using a plugin by Dyson Simmons, the unofficial docker-options plugin. I even pointed users at it for a while. At some point, we decided to integrate it into the core, and it was implemented in #1080 by Michael Hobbs and released in 0.3.17.

    Even back then, the first comment was \"How do I use this to have persistent storage?\". In retrospect, yes, this is a great feature to have in the core, and the new docker-options plugin was a bit too much like shiny plumbing. While the maintainers were distracted with other issues, the hack-fix was to update the documentation to have persistent storage as the example usage.

    Dokku implemented this feature in 0.5.0 as the storage plugin thanks to Justin Clark. The interface is a nice piece of porcelain that utilizes the same plugin triggers that the docker-options plugin exposes, except handles the very specific case of attaching persistent storage. It has resulted in many fewer support requests, and I believe has provided developers with a much nicer Dokku experience.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#where-is-the-resource-porcelain","title":"Where is the resource porcelain?","text":"

    The Dokku team has yet to see a nice interface to limiting resources of the following kind:

    These are the common resources which dokku users may wish to limit for specific applications, and having a good ui is more important to us than implementing a feature off the cuff.

    We also need to consider how such a tool integrates with other Dokku features. The storage plugin works great as a standalone plugin, but it may not be ideal to have a plugin for each type of resource. As well, resource limitation in docker has a few different implementations, depending upon what your exact requirements are. Ideally the Dokku solution is a generic one which 80% of our users are happy with, and the 20% that are not can drop down to plugin triggers or the docker-options plugin.

    At the end of the day, this porcelain is defined by you, our users. Want this feature sooner rather than later? Submit a pull request with an implementation, and we'll help shepherd it along to a state where everyone will be happy to use it.

    ","tags":["dokku","resource-management"]},{"location":"2016/resource-management/#alerting-on-resource-usage","title":"Alerting on Resource Usage","text":"

    While dokku manages the lifecycle of application containers, it does not and almost certainly will never manage monitoring and alerting on that usage. If your application does not have resource limitations in place, or hasn't run a background task in a while, or maybe just isn't running, that is your responsibility as a server operator to monitor/correct. Our recommendation here is to send logs/metrics to whatever upstream provider of metrics you prefer. Here are some awesome options:

    As many of our users have never actually maintained a server, we can certainly do more to help push our them in the right direction. In the next few weeks, we will be putting together a document that will gently push our users towards providers that may be able to take care of their needs, as well as clearly delineate where Dokku draws the line in the sand in terms of server management.

    Tip

    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.

    ","tags":["dokku","resource-management"]},{"location":"2016/welcome-to-dokku/","title":"Welcome to Dokku!","text":"

    Hi all! The dokku maintainers finally decided it was a good idea to have a blog to post thoughts on the development, evolution, and roadmap of Dokku. Our goal with these posts is to help inform you - dokku users and developers - as to where dokku is headed both internally and externally.

    Tip

    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.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-dokku","title":"What is dokku?","text":"

    Dokku is a docker-powered PaaS that helps you build and manage the lifecycle of applications.

    That is the spiel you get from our Site's metadata, the blurb on github, and even the footer on this blog. But what does it actually mean?

    Dokku is a somewhat loose set of scripts that are combined together as a sort of \"build\" pipeline. The input is your code, and the output is (hopefully) a running application. The pipeline looks something like the following:

    git push dokku master\n# magic\ncurl -kSso /dev/null -w \"%{http_code}\" \"http://your-app.example.com\" | grep 200\n
    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-magic-in-the-dokku-pipeline","title":"What is \"magic\" in the dokku pipeline?","text":"

    The \"magic\" comes from several pieces of tech:

    All three named pieces of software came from the original creator of Dokku, Jeff Lindsay. Both sshcommand and plugn are now wholly maintained by the Dokku Team, while the latter is currently under the care of Glider Labs, with maintenance being done by the Dokku Team as necessary.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-are-these-various-scripts","title":"What are these \"various scripts\"?","text":"

    It's important to note that dokku is by and large composed of shell scripts targeting modern bash. Why?

    Features are built as \"plugins\" which are triggered by plugn. For example, here are a few different official plugins:

    Plugins can be built in any language - in fact, some prototypes have been written in a hybrid of golang/bash or python. For the foreseeable future, however, we do not envision rewriting the core in another language.

    ","tags":["dokku","update"]},{"location":"2016/welcome-to-dokku/#what-is-the-goal-of-dokku","title":"What is the goal of dokku?","text":"

    Dokku's goal is to provide a simple, hackable build environment for developers to quickly get their code from their laptops into the cloud. Our personal goal is to make the deployment part easy, so all you have to do is worry about writing code.

    Tip

    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.

    ","tags":["dokku","update"]},{"location":"2018/the-dokku-experience/","title":"The Dokku Experience","text":"

    Dokku has historically had no way to introspect on the state of an installation. At one point in its history, we included a \"backup\" feature, which allowed users to export - and maybe import - configuration and data. The challenge is in exposing this information in an easily parseable manner.

    Tip

    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.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#plumbing-vs-porcelain","title":"Plumbing vs Porcelain","text":"

    To understand the challenges better, it is important to note that the internal representation of the state of Dokku is very different from how users interact with it. Data is stored in either /home/dokku/APP or /var/lib/dokku. Plugins may also store data on another host, and some implementations of the config plugin actually store configuration in distributed datastores. Dokku interacts with this data via a series of plugins - written in various languages - through plugn. This hairy mess is Dokku's Plumbing.

    Externally, developers use the dokku cli to orchestrate their applications. This is a well-known interface with clear documentation and usage examples. The cli rarely changes drastically, only doing so to allow for new functionality in a way that does not break existing use. The output format also rarely changes in backwards incompatible ways. If you know how to use one Dokku installation from 2 years ago, a modern install will be extremely familiar to you. This nice interface is called the Porcelain.

    The analogy is thus: most folks using a restroom are well-acquainted with a toilet, every toilet is similar, allowing for differences in color, size, and features - a bidet could be nice, as could an auto-flush feature. Very few folks know anything about the pipes that move waste and water around, only caring when it is broken or needs updating to support newer toilet features. The important thing is that you know how to use the toilet, that it does what you expect, and that you don't need to re-learn how to use it.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#a-common-interface","title":"A Common Interface","text":"

    When you use Dokku, you'll notice a few things:

    If you use Dokku, you only need to learn those patterns once. It is easy to figure out what is available, and straightforward to introspect upon the state of the system. This translates into the following:

    One thing I didn't touch upon is that our output is more or less machine parseable. It is not in json/xml/toml, but you can easily:

    The consistency here paves the way for automation.

    ","tags":["dokku","interfaces"]},{"location":"2018/the-dokku-experience/#interfacing-with-dokku","title":"Interfacing with Dokku","text":"

    While we have a cli aimed at humans, as developers, we yearn for interfaces computers can automate. Our next blog post will cover how developers may interact with Dokku in a declarative fashion in order to ensure that their servers and applications are configured as expected.

    Tip

    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.

    ","tags":["dokku","interfaces"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/","title":"Comparing Cloud Native Buildpacks to Herokuish","text":"

    An upcoming piece of technology in the container space is Cloud Native Buildpacks (CNB). This is an initiative led by Pivotal and Heroku and contributed to by a wide range of community members, and one that the Dokku project has been following fairly closely. CNB builds upon the buildpack \"standard\" initially developed at Heroku, modified at Pivotal for Cloud Foundry, and used/abused by the gliderlabs/herokuish project. This post goes over a small amount of history, compares buildpack implementations across vendors, and talks about the future of buildpacks as they relate to Dokku.

    Tip

    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.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#history-channel-vault","title":"History Channel Vault","text":"

    When Heroku first launched, they provided support for Rack applications, which worked fairly well for the budding Ruby community. As the Ruby community grew, this initial support started to become limiting for their users, and thus the Heroku community started reworking their internal tech to be more flexible in functionality they supported and how they launched processes, In fact, a lot of the fancy features and patterns you'll see in a modern PaaS - 12 factor apps, Procfile support, etc. - were first prototyped or promoted by Heroku. The process of detecting support, building app slugs, and releasing the built artifacts was one such initiative. Eventually, Heroku rebuilt their platform to support alternative programming runtimes as well as community contributed runtimes in what is now known as a buildpacks.

    As time marched on, the Cloud Foundry software from Pivotal picked up the buildpack tech. This would seem like an overall great thing for the community - buildpacks that have better support for enterprise environments and needs would certainly help with adoption in the corporate world - but ended up being not as great. As there was no real specification for Buildpack technology, Pivotal ended up diverging from Heroku's implementation, resulting in:

    For buildpack authors, the standards were largely compatible - and it would likely be possible to support both at once - but in practice you really only wrote a buildpack for the platform you were using. This also meant that new features for, say, the NodeJs buildpack would need to be implemented twice in order to be supported on these two platforms.

    Additionally, the buildpack spec never specified anything about the underlying platform, so building a buildpack for Heroku's platform that depends on some OS-level dependency might not work at all when used with Cloud Foundry or vice versa.

    Suffice to say, this divergence isn't great for the community, nor great for pushing the technology forward. I'll skip all the details - mostly because I don't know them! - but the emergence of containers and related technologies enabled the folks at Heroku and Pivotal to combine efforts to on a unified v3 specification, which is now CNB. Think of it as two mini lion bots coming together to form one super-bot!

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#comparing-buildpack-tech","title":"Comparing Buildpack tech","text":"

    While the new specification - still under development - provides a new, unified way to create and distribute buildpacks, there can still be differences between platforms. At this point in time, there are actually two different main \"builders\" - a collection of buildpacks - that folks in the community can use to play around with CNBs (both are based on the Bionic stack). They do provide slightly different functionality, so a comparison between them seems like a reasonable thing to do. We'll also compare CNBs to gliderlabs/herokuish, which is the main OSS implementation of the buildpack v2a technology.

    Note

    At the time of writing, Heroku's builder contains v2a buildpacks with a shim to allow them to run under the v3 specification. Additionally, there is a possibility that the organizations will collaborate on buildpacks in the future - who wants to rebuild the wheel? - but this is sort of all in the air. Please keep this in mind if reading this blog post a few months/years from the time of publication.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#installing-dependencies","title":"Installing dependencies","text":"

    For local testing, the CNB project provides the pack cli tool to simulate what would be available in a platform. There are related projects for Kubernetes and other tools in the deployment space, but pack is great for local testing, so we'll want to install that.

    # on a mac with homebrew\nbrew install buildpacks/tap/pack\n\n# everywhere else, go to the following page and download a release\n# https://github.com/buildpacks/pack/releases\n

    CNB splits buildpacks such that there is a \"build\" base image and a \"run\" base image. Apps are built within the build base image and then the layers are rebased onto the run image for distribution. This allows for the distributed image to be smaller in size, as well as avoids the need for distribution of compile-time dependencies. Both of these images need to be available on the machine that is running the build process.

    # cloudfoundry\ndocker image pull cloudfoundry/cnb:latest     # build\ndocker image pull cloudfoundry/run:full-cnb   # run\n\n# heroku\ndocker image pull heroku/buildpacks:18        # build\ndocker image pull heroku/pack:18              # run\n

    On the herokuish side, there is a single image that contains both compile and runtime dependencies. You can export a slug from the built image and run that on a system without the installed runtime dependencies, but in practice very few people do so.

    docker image pull gliderlabs/herokuish:latest # build and run\n

    Neither Cloud Foundry nor Heroku currently publish a Dockerfile for their images, so they are still somewhat of a black box. It's also not super clear from the documentation as to what the bionic stack is. We can only hope - but not assume - that these will be published for public recreation in the future.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#building-apps","title":"Building apps","text":"

    The app we'll be playing with is the node-js-getting-started app by Heroku. You can play around with your own app to see the results; also NodeJs is currently supported with both builders as well as the gliderlabs/herokuish project.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-cnb","title":"With CNB","text":"

    Building an app with CNB is the same regardless of your chosen builder, which is nice. The following command will build the app in the current directory with the Cloud Foundry builder:

    pack set-default-builder cloudfoundry/cnb:latest\npack build --no-pull --path . \"app/nodejs-cloudfoundry:latest\"\n

    Whereas utilizing the Heroku builder is not much different:

    pack set-default-builder heroku/buildpacks:18\npack build --no-pull --path . \"app/nodejs-heroku:latest\"\n

    Note that there is a volume cache used for dependencies for both buildpacks. At the time of writing, this can be computed like so:

    IMAGE=\"app/nodejs-cloudfoundry:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\n

    At the time of writing, there isn't a way to clear out that cache volume, so you can use the above method to compute the volume name. Please note that clearing this cache volume does not necessarily clear out any app image layers created, so this may not do exactly as you'd expect if you are interacting with a remote registry.

    If you are rebuilding an app using pack, you'll notice that there doesn't appear to be any caching with the Heroku builder. This might be a bug due to shim usage, and will likely be resolved in the future, but for now should expect this to be the case.

    Note

    As an aside, the buildpacks/lifecycle project - and therefore pack - creates OCI compatible images, so tooling that only works with the older Docker Image Specification may fail when using pack-built images.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-herokuish","title":"With Herokuish","text":"

    Building an image with gliderlabs/herokuish is a bit more complicated. While it is distributed as a binary and a docker image, most folks default to using the docker image. Some platforms - notably Gitlab - utilize it via a Dockerfile, but this doesn't allow you to take advantage of build cache. The below simulates the patterns used by the pack cli tool:

    # use a cache volume\n# this can also be substituted with a directory on disk\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker volume create $CACHE_VOLUME >/dev/null\n\n# run the build process\nIMAGE=\"app/nodejs-herokuish:latest\"\ndocker container run --cidfile /tmp/cid --env USER=herokuishuser -v \"${CACHE_VOLUME}:/tmp/cache\" -v $PWD:/tmp/app gliderlabs/herokuish:latest /bin/herokuish buildpack build\n\n# create your final image\ndocker container commit $(cat /tmp/cid) \"$IMAGE\"\n\n# cleanup\ndocker container rm $(cat /tmp/cid)\nrm -f /tmp/cid \n
    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#running-an-app","title":"Running an app","text":"

    This part is likely the most similar thing across all platforms. Both the CNB images utilize a special launcher process to run your process type for you, so all you really need to do is specify that process type.

    # cloudfoundry\ndocker container run -d -p 5000 --env PORT=5000 --name app.nodejs.cloudfoundry app/nodejs-cloudfoundry:latest web\n

    Docker log output on that container looks something like the following:

    > node-js-getting-started@0.3.0 start /workspace\n> node index.js\n\nListening on 5000\n

    Heroku is pretty similar

    # heroku\ndocker container run -d -p 5000 --env PORT=5000 --name app.nodejs.heroku app/nodejs-heroku:latest web\n
    Listening on 5000\n

    With herokuish, you need to execute the process type with the /start prefix. We also need to specify the USER, as this will be used by herokuish to properly set file permissions on the /app directory.

    docker container run -d -p 5000 --env PORT=5000 --env USER=herokuishuser --name app.nodejs.herokuish app/nodejs-herokuish:latest /start web\n
    Listening on 5000\n

    Startup time is a bit longer with herokuish as it will change ownership on files within the /app directory.

    Another difference between the two is the environment within which both images run in, which we'll get into next.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#inspecting-the-built-image","title":"Inspecting the built image","text":"

    Once we have a running app, lets inspect our artifact.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-cnb_1","title":"With CNB","text":"

    Executing a command on the CNB-backed containers is the same as executing a command with any other docker image. Processes are automatically invoked within the correct app environment, which is great for one-off commands.

    # cloudfoundry\ndocker container exec app.nodejs.cloudfoundry id\n
    uid=2000(vcap) gid=2000(vcap) groups=2000(vcap)\n
    # heroku\ndocker container exec app.nodejs.heroku id\n
    uid=1000(heroku) gid=1000(heroku) groups=1000(heroku)\n

    Ditto for process inspection:

    # cloudfoundry\ndocker container exec app.nodejs.cloudfoundry ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nvcap        35  0.0  0.1  34404  2856 ?        Rs   02:43   0:00 ps auxf\nvcap         1  1.2  2.2 739020 45136 ?        Ssl  02:43   0:00 npm\nvcap        22  0.0  0.0   4632   828 ?        S    02:43   0:00 sh -c node index.js\nvcap        23  0.6  2.0 573156 41896 ?        Sl   02:43   0:00  \\_ node index.js\n
    # heroku\ndocker container exec app.nodejs.heroku ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nheroku      22  0.0  0.1  34404  2856 ?        Rs   02:47   0:00 ps auxf\nheroku       1  0.9  1.7 566792 36728 ?        Ssl  02:46   0:00 node index.js\n

    Please bear in mind that PID 1 in the container will depend upon what the buildpack launches. Aside from that note, there is nothing new with CNB and pack in regards to running commands when compared to normal docker operations, so anyone familiar with Docker will feel right at home.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#with-herokuish_1","title":"With Herokuish","text":"

    On the herokuish platform, a process must be executed with the /exec command as a prefix. This will give you an environment that simulates running a command in the heroku stack.

    docker container exec app.nodejs.herokuish /exec id\n

    The output of the above command is:

    uid=32767(herokuishuser) gid=32767(herokuishuser) groups=32767(herokuishuser)\n

    Inspecting processes is pretty similar:

    docker container exec app.nodejs.herokuish /exec ps auxf\n
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND\nroot       287  0.0  0.1   5628  2448 ?        Ssl  02:57   0:00 /exec ps auxf\nherokui+   298  0.0  0.1  34404  2844 ?        R    02:57   0:00  \\_ ps auxf\nroot         1  0.2  0.1   5628  2448 ?        Ssl  02:57   0:00 /start web\nherokui+    13  2.7  1.9 566160 40020 ?        Sl   02:57   0:00 node index.js\n

    You'll notice that, in addition to your app, there is also the /start web process. This spawns your app with the correct environment, so just a bit different from CNB containers.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#cleaning-up","title":"Cleaning up","text":"

    Removing the containers and images is relatively straightforward, as we use traditional docker commands.

    # cloudfoundry\nIMAGE=\"app/nodejs-cloudfoundry:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.cloudfoundry >/dev/null 2>&1|| true\ndocker image rm cloudfoundry/run:base-cnb cloudfoundry/run:full-cnb cloudfoundry/cnb:latest >/dev/null 2>&1|| true\ndocker image rm app/nodejs-cloudfoundry:latest >/dev/null 2>&1|| true\n\n# heroku\nIMAGE=\"app/nodejs-heroku:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.heroku >/dev/null 2>&1|| true\ndocker image rm heroku/pack:18 heroku/buildpacks:18 >/dev/null 2>&1|| true\ndocker image rm app/nodejs-heroku:latest >/dev/null 2>&1|| true\n\n# herokuish\nIMAGE=\"app/nodejs-herokuish:latest\"\nCACHE_VOLUME=\"pack-cache-$(echo -n \"index.docker.io/$IMAGE\" | sha256sum | cut -c1-12).build\"\ndocker volume rm $CACHE_VOLUME >/dev/null 2>&1|| true\ndocker container rm -f app.nodejs.herokuish >/dev/null 2>&1|| true\ndocker image rm gliderlabs/herokuish:latest >/dev/null 2>&1|| true\ndocker image rm app/nodejs-herokuish:latest >/dev/null 2>&1|| true\n
    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#dokku-and-cloud-native-buildpacks","title":"Dokku and Cloud Native Buildpacks","text":"

    In an ideal world, all the functionality currently provided by Heroku's v2a Buildpacks and its ecosystem would immediately exist with Cloud Native Buildpacks. Unfortunately, the spec is still evolving - though nearing a v1! - and the user-base is comparatively small. If you are a buildpack author or a vendor using buildpack technology, now is likely the best time to get involved and raise concerns with the spec and ecosystem.

    That said, Dokku has active development towards the addition of CNB to the platform. In our case, we will likely have it as an experimental feature controlled through the use of environment variables, and folks will be able to switch their installations between CNB and Herokuish. This will also likely require changes to certain plugins - in particular, those that interact with the built images - but these will hopefully be fairly minimal.

    Long-term, the plan is to deprecate and eventually remove gliderlabs/herokuish support. The purpose of the Herokuish project was to allow folks to emulate the Heroku build/runtime environment. Heroku - amongst others - will be moving to CNB at some point, and already provide a shim for existing buildpacks in the new system. So in theory, any CNB platform would be able to use that shim + any tooling that supports CNB for buildpack support.

    The pack cli tool already provides a way for folks to build and run applications, and analogs for most herokuish cli commands. Given that:

    The best course of action is for Herokuish to become unsupported once pack hits a stable release. It is unlikely that support for Herokuish will continue at that point, and only general maintenance work (upgrading buildpacks) would be performed at that time. Long-term, the project will likely be archived completely in favor of the upstream CNB projects.

    There isn't any timeline for the above other than experimental support for CNB in Dokku will land at some point in the near future, so folks installing and using Dokku won't need to worry too much about the process. Long-term, there will be a migration path outlined for users, and how that impacts users will depend on how much tooling is necessary to shim in the existing ecosystem around buildpacks. We hope to keep this minimal, but sometimes you need to break some eggs to make an omelette.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/comparing-buildpack-v3-to-herokuish/#cloud-native-buildpacks-are-the-future","title":"Cloud Native Buildpacks are the future","text":"

    The Dokku project is incredibly excited about Cloud Native Buildpacks and it's implications for speeding up how we build secure applications and services. While the existing community is fairly small, the contributors are very dedicated to getting everything just right, and we expect that this will be a great boon to users of both Dokku and buildpacks in general.

    If you'd like to have a say in how the CNB initiative develops, please feel free to join in with development or comment in the Slack community - they are a bunch of very friendly folks - where much of the current development is focused.

    Tip

    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.

    ","tags":["dokku","buildpacks","herokuish"]},{"location":"2020/dokku-0.20.0/","title":"Dokku Release 0.20.0","text":"

    Dokku version 0.20.0 - and a few follow-on bugfixes - was released this week with quite a few major improvements, mostly to proxying and networking. We'll go over major changes below.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#changes","title":"Changes!","text":"","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#code-deprecations-and-removals","title":"Code Deprecations and Removals","text":"

    As noted in the migration guide, we removed quite a few default commands. These were replaced with :help output, and :list commands were provided where possible.

    We've also dropped support for unsupported versions of Debian and Ubuntu. Dokku no longer runs tests on older versions of Ubuntu, and Debian support for older releases was completely untested. While newer packages may work in the future, users should upgrade their operating systems where possible.

    Finally, quite a bit of code was moved into golang, and as such certain shell functions are deprecated in favor of new plugin triggers. Usage will trigger warnings in logging output. Please switch to the new triggers in custom plugins where possible, as we well continue to remove deprecated code in the future.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#custom-networks","title":"Custom networks","text":"

    In previous versions of Dokku, containers could only communicate with each other through one of the following methods:

    The first option was great for apps that were architected to do message passing, but almost a non-starter for certain self-hosted apps. Even for new apps, adding an intermediate communication layer will always increase the number of problems that could occur in a system, so it was far from optimal.

    Sending traffic over the open network is not great as for many users, this would mean traffic over the internet. Sending traffic over the open network increases latency between requests, increases bandwidth usage - and costs! - and opens users to potential security issues regardless of SSL encryption. Suffice to say that this was also not a great solution.

    Adding a custom --network flag via the docker-options plugin works well enough but has a few issues itself:

    A user created a custom plugin to attach on to networks after deploy, but this also has the side effect of not supporting containers that need to talk to a specific network on boot.

    With the new network support added in 0.20.0, users can easily create/destroy attachable docker networks, and ensure apps attach to those networks at the correct time for their apps via two easy-to-configure hooks. From the documentation:

    This feature has been a long time coming - it was originally reported in 2016 - and was also a ton of work, but we hope that it provides great value to our users.

    Here is a fun incoming bandwidth chart of a user switching to the new network support for their apps:

    See the network documentation for more information

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#routing-non-web-containers","title":"Routing non-web containers","text":"

    Users wishing to route non-web containers would previously have to either hack their nginx config or use a custom plugin to try and inject location and upstream blocks into the correct place. The lack of built-in support made it difficult to support cases where there might be a websocket process, or some command-and-conquer service that exposed a tcp connection in addition to the traditional web process.

    As of 0.20.0, we now inject a custom .DOKKU_APP_${PROCESS_TYPE}_LISTENERS variable into all nginx.conf.sigil files. This will allow folks to inject http(s) processes into the nginx.conf.sigil, which brings initial support for proxying non-web processes.

    Future improvements might include tcp support - via the nginx stream module - and injection of custom location blocks for even easier proxying of non-web processes.

    Users are encouraged to switch their custom configs to use the new .DOKKU_APP_WEB_LISTENERS variable when constructing upstreams. See the nginx template documentation for more information.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#hsts-enabled-by-default","title":"HSTS Enabled by Default","text":"

    If you have an SSL certificate and are proxying requests using the nginx plugin, then HSTS will be enabled by default. It is enabled by default - including for subdomains - though without browser preloading. Please note that the default cache setting is 182 days, so pre-configure this value if you believe you will need to manipulate HSTS support.

    See the nginx hsts documentation for more information.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#restarting-docker-containers-recover-from-ip-changes","title":"Restarting docker containers recover from IP changes","text":"

    Docker has undefined behavior around IP address persistence when containers restart, either due to failure or because of server reboot. This has resulted in issues where restarting containers lose their IP addresses, breaking any proxy method that is associated with a container IP instead of the container name (read: how Dokku works!). This sometimes caused nasty issues where apps deployed on Dokku might mistakenly have their nginx route incorrect apps to users on server reboot, or just straight-up fail to serve requests even when the app is working after a container restart.

    In 0.20.2, we included the dokku-event-listener as a recommended package. It is usable with older versions of dokku, and can be installed like so:

    # update your apt repository\napt update\n\n# install it!\napt install dokku-event-listener\n

    The dokku-event-listener daemon will properly listen to container events - start, restart, delete, destroy, die - and reload the nginx config for the related app as appropriate. It will even rebuild the application if we've hit the max container restart count. It will also output debug logging that you can use to correlate application crashes with service outages.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.20.0 migration guide for more information on upgrading to 0.20.0.

    ","tags":["dokku","release"]},{"location":"2020/dokku-0.20.0/#future-development","title":"Future development","text":"

    As Dokku continues to mature towards a 1.0 target, the following areas will be of greater focus in upcoming releases:

    As always, please post issues with bugs or functionality you think Dokku might benefit from. As well, feel free to hop onto our IRC or Slack channel if you have questions, comments, or concerns.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/","title":"Dokku Release 0.23.0","text":"

    Dokku version 0.23.0 was released this weekend with quite a few major improvements for many common workflows. We'll go over major changes below.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#new-core-contributors","title":"New Core Contributors","text":"

    With the new release, a few folks have been added as contributors to the project.

    These folks have been added as Github Triagers to various projects. This means they'll have increasing control over the future of the project and features they think they'd like in the core, as well as how those things might be developed over time. You can think of them as community++ :)

    While they have been added as core contributors, as this is an Open Source Project, there is no requirement of any work from them. This is simply recognition for the great work they've done to support Dokku.

    How do you join? There are a number of ways to Contribute to the project, code and otherwise. As we continue to clean up various projects under the Dokku umbrella, more folks will be added (and removed as necessary) to help push the project forward. We hope that this helps unblock pull requests from being merged, features from being developed, and bugs from being squashed.

    Thanks to the folks above and all community contributors. It would be hard to imagine Dokku without all of you pushin the project forward.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#circleci-github-actions","title":"CircleCI => Github Actions","text":"

    CircleCI was and remains a great service - we'll continue to use them for other projects unless there is a real need to switch. They certainly provide a wide-range of features, and will be the recommended CI stack for folks needing serious CI functionality.

    That said, our CircleCI usage was limited for a few reasons:

    With 0.23.0, we've switched to Github Actions, which provides the following benefits:

    While not all functionality has been carried over - in particular, test statistics are missing, it is impossible to re-run only failing jobs, and running jobs with SSH for debugging is a bit more difficult - it is hoped that the change makes the process of developing new functionality much easier for the average contributor.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#image-labeling","title":"Image Labeling","text":"

    Dokku introduced label-schema.org support as part of 0.18.0 back in August of 2019. While Label Schema is no longer actively maintained - in favor of OCI Annotations tha we'll properly support in the near future - we still label images and labels according to that spec. Unfortunately, our labeling support left a lot to be desired.

    As of 0.23.0, the Dokku project now uses docker-image-labeler to inject labels only when necessary, and avoids building new containers entirely. This should have no real impact on produced images, though will reset layer create times as a side effect (a limitation that may be removed in the future).

    We'll continue to investigate similar ways to speed up the build process for all of our users in future releases.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#libpam-tmpdir-support","title":"libpam-tmpdir support","text":"

    As part of an increased focus on security, we've added proper libpam-tmpdir support. The actual problem was due to how we attempt to drop permissions via the sudo binary without resetting certain environment variables.

    While the fix was relatively simple - just unsetting some variables - our implementation of permission dropping certainly leaves something to be desired. Enterprising individuals who wish to contribute to the project and have expertise in this area would certainly be welcomed!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#buildpack-stack-builder-management","title":"Buildpack Stack Builder Management","text":"

    In previous releases, users of derivative gliderlabs/herokuish images would need to specify a DOKKU_IMAGE environment variable in order to use their version over what we ship by default. While this was a reasonable approach that worked when there was only one herokuish image version being maintained, we've recently decided to add support for building both 18.04 and 20.04 based images. Additionally, this approach does not work at all for our Cloud Native Buildpack support.

    As of 0.23.0, there is now a way to set the stack builder image in use. Herokuish users (the majority of Dokku users at this time) will be able to specify either the 18.04, 20.04, or any other image as follows:

    # app-specific command\ndokku buildpacks:set-property $APP $SOME_IMAGE\n\n# global command\ndokku buildpacks:set-property --global stack $SOME_IMAGE\n

    Any tag listed on Docker Hub can be used, and folks can derive their custom herokuish image as needed for their own platforms. For general users, we highly recommend sticking to the shipped defaults.

    Cloud Native Buildpack users have access to the same command, and can use it to specify an alternative builder image. Below switches the global builder image from heroku/buildpacks to the packeto buildpacks maintained by CloudFoundry:

    dokku buildpacks:set-property --global stack paketobuildpacks/build:base-cnb\n

    We'll continue working to add full support for buildpacks commands to the Cloud Native Buildpack support, and hope this initial work makes it easier to use.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#container-logrotation","title":"Container Logrotation","text":"

    With the addition of Vector-based Log Shipping in 0.22.x, we still had a need to ensure logs didn't consume host resources. Assuming default docker log settings, it is now possible to set the docker log retention via logs:set:

    dokku logs:set --global max-size 20m\n

    This new setting injects a property into the docker run calls (though is exposed via trigger for alternative schedulers), defaults to 10m, and can be set both globally and on a per-app basis. Please rebuild your apps to have this come into effect.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#nginx-configuration","title":"Nginx Configuration","text":"

    While having a sane default is great, often-times users will need to customize their nginx proxy configuration to meet their needs. Vendoring a custom nginx.conf.sigil makes it more difficult for us to ship security updates to users, and thus we're opening the floodgates to new knobs for configuring the nginx config built for apps.

    The following new properties can now be set on a per-app basis:

    While the hsts property can now be set globally (default on) in addition to on a per-app basis.

    We'll continue adding support to additional properties (both globally and otherwise) as the needs arise from the community. Checkout our nginx documentation for further details.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#scheduled-cron-task-management","title":"Scheduled Cron Task Management","text":"

    For years, we've asked folks to manage a custom cron file outside of the Dokku deployment process. While this was all well and good, it doesn't work well for less technical users or those who do not have server access. We've added support to the app.json file for specifying a list of commands and the schedule for which to run said commands. Usage is simple:

    {\n  \"cron\": [\n    {\n      \"command\": \"node run some-command-here\",\n      \"schedule\": \"@daily\"\n    }\n  ]\n}\n

    Scheduled cron tasks are run within isolated Docker containers, and any number of commands can be added to a given app. While this isn't currently supported in alternative schedulers, the functionality was built with such support in mind.

    Checkout the scheduled cron task documentation for more details on how the functionality works. We'd definitely love your feedback!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#git-repository-syncing-support","title":"Git Repository Syncing support","text":"

    This is one of the more exciting features. Users may now run a command to specify a remote repository to sync - and build! - an app from via the git:sync command. This makes it possible to build webhook-like functionality by wrapping the command in a web api of sorts.

    # just sync some code, maybe to setup a repository\ndokku git:sync node-js-app https://github.com/heroku/node-js-getting-started.git\n\n# sync and build the repository!\ndokku git:sync --build node-js-app https://github.com/heroku/node-js-getting-started.git\n

    We hope to continue adding interesting git-based workflows in upcoming releases, but hope that this feature is well-used by platform developers.

    Thanks to @crisward for the inspiration via his dokku-clone project.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.23.0 migration guide for more information on upgrading to 0.23.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.0/#10","title":"1.0?","text":"

    Our versioning is getting long in the tooth, and we're quickly winding towards an eventual 1.0 release. It's been teased in the past, but as of this writing, there are currently 18 outstanding issues in the 1.0 milestone. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/","title":"Dokku 0.23.x Wrapup","text":"

    Dokku version 0.24.0 was released earlier this week. This post covers the major changes that occurred throughout the lifetime of the 0.23.x series. A future post will cover the 0.24.0 release.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#release-changes","title":"Release changes","text":"

    Dokku now has support for triggering releases via Github Actions. This will allow any maintainer to make a release of Dokku without needing to set anything up locally. The ability to auto-release plugins and tools in the Dokku ecosystem will slowly be added to all core projects over the coming weeks.

    In addition, we now update the official Azure ARM template for Dokku during the release process, as well as bump the homebrew repo for the remote cli tool. We hope to extend this official release bumping to other image maintained for Dokku in the near future.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#report-output-as-json","title":"Report output as json","text":"

    While undocumented, all of the golang plugins now support displaying report output as json (#4369). This makes it easier for tools to parse the reports.

    A future release will hopefully extend this to all plugins, and provide a framework for non-core plugins to also have json formatting support in :report output.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#modifying-x-forwarded-ssl-in-nginx-configurations","title":"Modifying X-Forwarded-Ssl in nginx configurations","text":"

    Some load balancers require specifying a value for X-Forwarded-Ssl. The ability to do so was added in #4420. Note that this is a non-standard version of setting x-forwarded-proto to https, and should only be done as a last resort.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#add-support-for-injected-cron-entries-from-external-plugins","title":"Add support for injected cron entries from external plugins","text":"

    One of the things lost by the addition of scheduled cron task support in 0.23.0 was the ability to set cron tasks from plugins. This functionality was used by the dokku-letsencrypt plugin to support it's auto-renew functionality.

    The change in #4384 allows alternative plugins - such as dokku-letsencrypt - to inject scheduled cron tasks into the cron system used by Dokku. Cron systems can choose to include or not include a cron task based on the specified scheduler, and can also optionally use a third parameter to store arbitrary information.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#ability-to-clear-an-individual-resource-value","title":"Ability to clear an individual resource value","text":"

    As of (#4372)[https://github.com/dokku/dokku/pull/4372], a resource value can be individually cleared by setting the value to the special value clear.

    dokku resource:limit --cpu clear node-js-app\n
    =====> Setting resource limits for node-js-app\n       cpu: cleared\n
    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#a-new-null-buildpack-was-added","title":"A new 'null' buildpack was added","text":"

    Herokuish 0.5.25 introduces a new null buildpack. This buildpack does nothing, which is useful if your app vendors all it's dependencies and does not need to be built.

    To use it, include a .null file in your app repository. No other changes are necessary.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#documentation-is-now-at-dokkucom","title":"Documentation is now at dokku.com","text":"

    The documentation has moved from the global viewdocs to it's own fork, hosted at dokku.com. Future documentation changes will enable embedded docs for official plugins, doc search, as well as including the blog on the main domain.

    As an added bonus, our documentation now has SSL!

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#checking-if-an-app-was-deployed","title":"Checking if an app was deployed","text":"

    Previously, checking if an app was deployed actually checked if there were any running processes. This is not only incorrect, but also fails to take into account applications that do not have running processes and are only used for one-off commands.

    The fix in #4402 migrates apps to the new \"deployed\" property which is set in core-post-deploy. The result is a slightly faster \"deployed\" check that is correct and allows non-scaled apps to actually work.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#better-procfile-extraction","title":"Better Procfile extraction","text":"

    As of #4373, the Procfile is now extracted in the pre-deploy step for every deploy and otherwise not removed. Thus, it should always exist when necessary - web will be scale to 1 automatically and it won't need to be present on future ps:scale calls since we'll have the scale file - and the command can execute faster.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.23.0 migration guide for more information on upgrading to 0.23.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.23.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    And that's it for 0.23.x. Our next post will cover 0.24.0, as well as plans for future releases.

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/","title":"Dokku Release 0.24.0","text":"

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#change-exit-code-when-app-does-not-exist","title":"Change exit code when app does not exist","text":"

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#support-for-herokus-postdeploy-deployment-task","title":"Support for heroku's postdeploy deployment task","text":"

    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 release phase.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#git-authentication-handling-via-netrc","title":"Git Authentication handling via .netrc","text":"

    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:

    There is no deploy key associated with the dokku user.\nGenerate an ssh key with the following command (do not specify a password):\n  ssh-keygen -t ed25519 -C 'example@example.com'\nAs an alternative, configure the netrc authentication via the git:auth command\n

    This should allow folks to figure out what they need to do.

    Lastly, the clone/fetch commands no longer use -qq or stderr redirection. If there are other errors, this will allow operators to have some debugging information.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#simplified-docker-image-deployment-via-gitfrom-image","title":"Simplified docker image deployment via git:from-image","text":"

    There are a ton of people that want to deploy a docker image. To do that, they currently need to:

    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.

    For 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 git:from-image.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#simplified-archive-deployment-via-gitfrom-archive","title":"Simplified archive deployment via git:from-archive","text":"

    Similar to 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 .tar, .tar.gz, and .zip files to apps, keeping git history with every deploy. In addition to a url, it also supports piping the archive in via stdin.

    The 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.

    For 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 git:from-image.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#specifying-app-builders","title":"Specifying app builders","text":"

    Dokku currently supports three different types of app builders:

    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 builder:set command.

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#parallelism-for-some-proxy-commands","title":"Parallelism for some proxy commands","text":"

    Being able to specify --all and increase parallelism of save commands is always great. As of 0.24.0, the commands proxy:enable, proxy:disable and 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 :)

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.24.0 migration guide for more information on upgrading to 0.24.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.24.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/","title":"Dokku Release 0.25.0","text":"

    With the 0.25.x release of Dokku a few weeks ago, a folks may have questions as to why they would want to upgrade and how it would impact their workflows. We've cherry-picked a few more important changes, but feel free to go through the release notes for more information.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#changes","title":"Changes","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#make-heroku-20focal-the-default-stack-for-herokuish-builds","title":"Make heroku-20/focal the default stack for herokuish builds","text":"

    With the release of newer versions of Ubuntu, the heroku-18 stack (based on Ubuntu 18.04) was getting a bit long in the tooth. We've since switched to heroku-20 as our default. Many apps will continue to work as before, though some with compiled dependencies may have issues. This may be fixed by either of the following:

    Users may also set the stack property globally by specifying --global instead of an app name.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#drop-web-installer-in-favor-of-setup-via-cli","title":"Drop web installer in favor of setup via cli","text":"

    Dokku has had a Web installer for years. This installer has been useful for getting started - especially when setup via a cloud image on popular hosting providers - but has been an open security risk for those that forget that it exists.

    Rather than try weird schemes to lock it down or notify users that it is still around, we've decided to remove it completely. It's usage is replaced by the following commands:

    # usually your key is already available under the current user's `~/.ssh/authorized_keys` file\ncat ~/.ssh/authorized_keys | dokku ssh-keys:add admin\n\n# you can use any domain you already have access to, also takes an IP address\ndokku domains:set-global dokku.me\n

    We strive to make Dokku secure by default, and this is a step in that direction.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#drop-support-for-ubuntu-1604","title":"Drop support for Ubuntu 16.04","text":"

    While our debian packages are generic enough to use on any Debian-based operating system, we've dropped support for Ubuntu 16.04 as it reached the public End of Life in April of 2021. This allows us to spend more time testing on newer systems. We've also added initial support for Debian Bullseye (in 0.25.2) for those using Debian's latest release.

    We will continue to add support for other operating systems as time goes on.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#new-features","title":"New Features","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#add-support-for-the-formation-key-in-appjson","title":"Add support for the formation key in app.json","text":"

    Dokku has long had support for a DOKKU_SCALE file that tracked repo-specified scaling settings for apps. This was also the name for a file on disk that held the scale contents. Code handling whether a user could scale or not was quite brittle.

    Users may now specify a formation key in their app.json file. This is similar to heroku, and currently supports scale quantity on a per-process basis.

    {\n  \"formation\": {\n    \"web\": {\n      \"quantity\": 1\n    },\n    \"worker\": {\n      \"quantity\": 4\n    }\n  }\n}\n

    The goal here is to consolidate various app config stored in a variety of files in repo into one app.json file. We'll be following Heroku's specification around this file where possible, but will extend it where necessary - as we did with Cron support in 0.23.x.

    See the process management documentation for more information on how to use this in your apps.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#add-monorepo-support","title":"Add monorepo support","text":"

    Some users may find a need to deploy an app several times with slightly different settings each time. This generally works by setting environment variables as necessary, but some things require changing which in-repo files are used. We've made changes across Dokku to respect changing the following:

    Feel free to file issues for any other files in use by Dokku that should be changed to allow better monorepo support.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#implement-the-registry-plugin","title":"Implement the registry plugin","text":"

    Users of the new git:from-image functionality introduced in 0.24 may have noticed missing support for authenticating against remote registries. This was added in the new registry management plugin, and generally supports the same interface you'd see with docker login:

    # hub.docker.com\ndokku registry:login docker.io $USERNAME $PASSWORD\n\n# password via stdin\necho \"$PASSWORD\" | dokku registry:login --password-stdin docker.io $USERNAME\n

    Additionally, schedulers other than the docker-local scheduler require that the deployed image be available on a registry. This plugin can be used for upload images after the build process completes.

    dokku registry:set node-js-app push-on-release true\n

    Images will be pushed to Docker Hub by default. Users may specify an alternative registry by setting the server property:

    dokku registry:set node-js-app server registry.digitalocean.com/\n

    Users of the community dokku-registry plugin should uninstall that plugin before upgrading Dokku, and then ensure that their apps are re-configured with the built-in plugin.

    See the registry management documentation for more information on how to use the registry plugin.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#revamp-the-dokku-run-command","title":"Revamp the dokku run command","text":"

    The dokku run command was often misunderstood. Users assumed the containers would disappear after use, and there was no way to understand what containers were running via dokku run.

    The new release automatically includes the --rm flag on containers created by dokku run. Users wishing to run detached containers should use the dokku run:detached command.

    We also introduced the run:list command, which can be used to list all containers created by dokku run (by filtering on the com.dokku.container-type=run docker label). Users will be able to quickly see what is currently running. In the future, users may be able to enter those running containers via run:enter, and remove any errant ones via run:destroy.

    Please note that implementation and semantics of dokku run are up to individual scheduler plugins.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#routing-to-non-dokku-managed-apps","title":"Routing to non-Dokku managed apps","text":"

    In some cases, it may be necessary to route an app to an existing $IP:$PORT combination. This is particularly the case for internal admin tools or services that aren't run by Dokku but have a web ui that would benefit from being exposed by Dokku. This can be done by setting a value for static-web-lister network property and running a few other commands when creating an app.

    # for a service listening on:\n# - ip address: 127.0.0.1\n# - port: 8080\n# create the app\ndokku apps:create local-app\n\n# set the builder to the null builder, which does nothing\ndokku builder:set local-app selected null\n\n# set the scheduler to the null scheduler, which does nothing\n\n# for dokku 0.25.x\ndokku config:set local-app DOKKU_SCHEDULER=null\n\n# for dokku 0.26+\ndokku scheduler:set local-app selected null\n\n# set the static-web-listener network property to the ip:port combination for your app.\ndokku network:set local-app static-web-listener 127.0.0.1:8080\n\n# set the port map as desired for the port specified in your static-web-listener\ndokku proxy:ports-set local-app http:80:8080\n\n# set the domains desired\ndokku domains:set local-app local-app.dokku.me\n\n# build the proxy config\ndokku proxy:build-config local-app\n

    The above takes advantage of new null builder and scheduler plugins that do nothing during the build or schedule phases.

    This functionality can be used when trying to expose non-Dokku maintained services to the external world without requiring a deployed proxy. One nice side-effect is that this also means users can expose services with letsencrypt support.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.25.0 migration guide for more information on upgrading to 0.25.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.25.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 14 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/","title":"Dokku Release 0.26.0","text":"

    It's been a little over two weeks since our 0.26.x release landed. Here is a summary of what features were added during the 0.25.x release and new stuff in 0.26.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#new-features-during-the-025x-series","title":"New Features during the 0.25.x Series","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#debian-bullseye-support","title":"Debian Bullseye Support","text":"

    #4742

    Dokku has supported both Debian and Ubuntu for quite a while - our packages are universal and actually can be installed all the way back to Ubuntu 14.04, even though we no longer officially support it. Bullseye came in a few days after the 0.25.0 release, so adding support for it made total sense.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#faster-herokuish-builds-when-injecting-environment-variables","title":"Faster Herokuish builds when injecting environment variables","text":"

    #4741

    Previously, herokuish buildpack builds would use intermediate containers for injecting the initial environment variables during the build process. This was actually quite slow - a container is created, started, some command is run, and then we create the image from that container - and also sometimes resulted in leftover containers if a build failed.

    We now initialize app environment variables via a special Dockerfile, which skips the intermediate container completely. Not only is this a bit faster, but we also no longer need to cleanup after the intermediate container.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#vscode-remote-container-support","title":"VSCode Remote Container Support","text":"

    #4785 #4791 #4800 #4814

    For anyone doing Dokku development, being able to simulate the entire environment is :major: for productivity. Setting up a virtual machine can be:

    We\u2019ve since added more complete support for developing in VSCode\u2019s Remote Container environment. In the future, supporting Azure and GitHub dev containers is in the cards, but this should enable most developers to more smoothly develop, test, and contribute to Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#schedule-process-types-in-parallel","title":"Schedule Process Types in Parallel","text":"

    Note

    This functionality was graciously sponsored by Rechat, a company doing remarkable efforts to help simplify and elevate how Real Estate Agents and Brokers operate.

    #4829

    Previously, we would deploy each container process type one at a time. For most users, this was not a huge deal, but users deploying apps with 10+ apps would encounter multi-minute deploys.

    As of 0.25.5, users can set the parallelism on processed process types. The web process is now always deployed first, while all other processes will deployed after the fact. The following command will set parallelism to 4 (default: 1) for non-web processes:

    dokku scheduler-docker-local:set $APP parallel-schedule-count 4\n
    This only applies to the list of process types scheduled at once, not individual containers within a process type.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#changes-in-026x","title":"Changes in 0.26.x","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#removal-of-deprecated-tags-and-tar-plugins","title":"Removal of deprecated tags and tar plugins","text":"

    #4858 #4859

    These two plugins were previously deprecated in 0.24.x in favor of git:from-image and git:from-archive, respectively. Rather than keep an unmaintained, buggy implementation of deployment, we\u2019ve completely removed these two plugins. Users should switch to the recommended methods of deployment, which are much more flexible and better integrate with Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#faster-restarts-and-single-process-restarts","title":"Faster restarts and single-process restarts","text":"

    #4765

    Previously a restart would result in a complete rebuild of an application. With this change, restarts will now only rebuild when the image does not exist, and otherwise simply restart processes with the built image.

    In addition, a user may restart just a single process type. While not common, this can be used as a proxy for killing processes that consume memory, while not requiring a full app rebuild or restart.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#increase-parallelism-for-containers-within-specific-process-types","title":"Increase parallelism for containers within specific process types","text":"

    #4860

    As a followup to #4829, apps deployed via the docker-local scheduler can now perform parallel scheduling for specific process types. The default configuration follows the existing behavior, while engineers that need extra parallelism on a per-process type basis can configure it via the app.json file:

    {\n    \u201cformation\u201d: {\n        \u201cweb\u201d: {\n            \u201cmax_parallel\u201d: 3\n        }\n    }\n}\n

    Parallelism defaults to 1 (previous behavior) but can be increased as needed.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#scheduler-management-plugin","title":"Scheduler Management Plugin","text":"

    #4857

    As we move towards a 1.0 release, Dokku\u2019s internal configuration that can be modified via environment variables is being moved into plugin-specific configuration settings. Setting a scheduler is one of them, and 0.26.0 will migrate the DOKKU_SCHEDULER environment variable to a scheduler plugin setting. Going forward, should set the scheduler via scheduler:set [app|\u2014global] selected call.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#raspberry-pi-support","title":"Raspberry PI Support","text":"

    #4885 #4887 #4888 #4889

    Dokku has always lived in the realm of self-hosting, but it was always x86-based. This completely precluded ARM users from using Dokku, which wasn\u2019t great for those who fully self-hosted, servers included.

    In the first few releases of 0.26.x, we\u2019ve added armhf architecture support, allowing those using Raspbian to install Dokku. Adding support for other ARM architectures should be rather trivial in the future (provided there is Golang support).

    Some notes:

    While there are some limitations, the general Dokku experience works quite well on ARM, and hopefully opens up experimentation to the general development community.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.26.0 migration guide for more information on upgrading to 0.26.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    We'll have more information in the coming week, but Dokku Pro will be provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.26.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 9 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/","title":"Dokku Release 0.28.0","text":"

    It's been a little over two weeks since our 0.28.x release landed. Here is a summary of what new stuff is in 0.28.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#changes-in-026x","title":"Changes in 0.26.x","text":"","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#removal-of-deprecated-tags-and-tar-plugins","title":"Removal of deprecated tags and tar plugins","text":"

    #4858 #4859

    These two plugins were previously deprecated in 0.24.x in favor of git:from-image and git:from-archive, respectively. Rather than keep an unmaintained, buggy implementation of deployment, we\u2019ve completely removed these two plugins. Users should switch to the recommended methods of deployment, which are much more flexible and better integrate with Dokku.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#faster-restarts-and-single-process-restarts","title":"Faster restarts and single-process restarts","text":"

    #4765

    Previously a restart would result in a complete rebuild of an application. With this change, restarts will now only rebuild when the image does not exist, and otherwise simply restart processes with the built image.

    In addition, a user may restart just a single process type. While not common, this can be used as a proxy for killing processes that consume memory, while not requiring a full app rebuild or restart.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#increase-parallelism-for-containers-within-specific-process-types","title":"Increase parallelism for containers within specific process types","text":"

    #4860

    As a followup to #4829, apps deployed via the docker-local scheduler can now perform parallel scheduling for specific process types. The default configuration follows the existing behavior, while engineers that need extra parallelism on a per-process type basis can configure it via the app.json file:

    {\n    \u201cformation\u201d: {\n        \u201cweb\u201d: {\n            \u201cmax_parallel\u201d: 3\n        }\n    }\n}\n

    Parallelism defaults to 1 (previous behavior) but can be increased as needed.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#scheduler-management-plugin","title":"Scheduler Management Plugin","text":"

    #4857

    As we move towards a 1.0 release, Dokku\u2019s internal configuration that can be modified via environment variables is being moved into plugin-specific configuration settings. Setting a scheduler is one of them, and 0.26.0 will migrate the DOKKU_SCHEDULER environment variable to a scheduler plugin setting. Going forward, should set the scheduler via scheduler:set [app|\u2014global] selected call.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#raspberry-pi-support","title":"Raspberry PI Support","text":"

    #4885 #4887 #4888 #4889

    Dokku has always lived in the realm of self-hosting, but it was always x86-based. This completely precluded ARM users from using Dokku, which wasn\u2019t great for those who fully self-hosted, servers included.

    In the first few releases of 0.26.x, we\u2019ve added armhf architecture support, allowing those using Raspbian to install Dokku. Adding support for other ARM architectures should be rather trivial in the future (provided there is Golang support).

    Some notes:

    While there are some limitations, the general Dokku experience works quite well on ARM, and hopefully opens up experimentation to the general development community.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.28.0 migration guide for more information on upgrading to 0.28.0.

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    We'll have more information in the coming week, but Dokku Pro will be provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2021/dokku-0.28.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 9 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/","title":"Dokku's Roaring 0.20s","text":"

    It's been a few months since the last release post, so we'll summarize whats been going on in Dokku Land in 2020.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#discussions","title":"Discussions","text":"

    Where should you get help? We've added Github Discussions support to the main project. Folks are encouraged to post questions and seek help from the community there. This will be a monitored channel, and is subject to the Code of Conduct.

    If you are seeking more \"live\" support, join the #dokku channel on the Gliderlabs Slack. A member of the core team - in addition to community members! - will attempt to help you given enough time and information.

    Users can continue posting to Stackoverflow or other locations, though those will not be actively monitored for issues.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#releases","title":"Releases","text":"","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#021x","title":"0.21.x","text":"

    We released quite a few major things in the 0.21.0 release:

    Other than the above, 0.21.0 was mostly a bugfix release. Hopefully it was to your liking.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#022x","title":"0.22.x","text":"

    The 0.22.x was a bit more expansive in the number of changes it introduced. There were a number of changes and deprecations, the most major of which were:

    What else showed up in 0.22.x?

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#cloud-native-buildpacks-support","title":"Cloud Native Buildpacks support","text":"

    Cloud Native Buildpacks are the future of Dokku's Buildpack support. We previously blogged about it, comparing it to our current Herokuish support. This new initiative is supported by a wide range of folks affiliated with the Cloud Native Computing Foundation, and we're hoping to see tighter integration with Dokku in the future.

    While it's still in development, this functionality is currently behind an app-specific environment variable and depends on the pack binary. To use it:

    # where $APP is your app name\ndokku config:set $APP DOKKU_CNB_EXPERIMENTAL=1\n\n# install pack: https://buildpacks.io/docs/tools/pack/\n# apt based installation in use here, but use what you are comfortable with\nsudo add-apt-repository ppa:cncf-buildpacks/pack-cli\nsudo apt-get update\nsudo apt-get install pack-cli\n

    Some future improvements:

    Definitely a space to watch.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#aggressive-container-cleanup","title":"Aggressive Container Cleanup","text":"

    Previous releases of Dokku would leave behind intermediate containers for debugging purposes. As Dokku has largely stabilized, these containers are no longer as necessary. The intermediate containers are commonly confused for containers that utilize server resources. Even worse, Docker will occasionally start these intermediate containers on reboot (Docker does not keep track of whether a container was manually stopped or not), causing actual performance issues for servers.

    In 0.22.x, we start deleting these intermediate containers at most 5 minutes after a deploy, and sometimes even sooner. We also cleanup images that may have been used during this process. While the cleanup time is not currently configurable, we hope that this change allows folks to feel better about resource utilization on more constrained servers.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#nginx-configuration-knobs","title":"Nginx Configuration Knobs","text":"

    While we attempt to ship with the best nginx configuration by default, folks may want to tune specific knobs to match their setup without needing to ship an nginx.conf.sigil that may become outdated. We've added an nginx:set command that can be used to set various nginx settings, and will continue to add more settings over time.

    Additionally, for installations that have a single nginx.conf.sigil that should be used amongst all apps by default, we've added the ability to set the location of the global defaults via a plugin trigger. This is exceptionally useful for platform creators that must inject some special configuration to integrate with their platform.

    Finally, if you wish to disable app-side nginx.conf.sigil extraction, we've added a tunable property for this via nginx:set (disable-custom-config). While this cannot currently be set globally or as a default, enterprising platform developers may create plugins that inject properties on app creation...

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#vector-based-log-shipping","title":"Vector-based Log Shipping","text":"

    This came late in the 0.22.x lifecycle (0.22.6/0.22.7), but was added to address the logging options issue (#2268). Vector is an open-source, lightweight and ultra-fast tool for building observability pipelines. Dokku integrates with it for shipping container logs for the docker-local scheduler. Users may configure log-shipping on a per-app or global basis, neither of which interfere with the dokku logs commands.

    Vector is based on the idea of inputs, transforms and sinks. Dokku will automatically inject the correct inputs for all Docker containers, and it is up to you to define a sink to which you can send container logs (globally or per-app). Dokku does not currently support customizing transforms, though this may come in a future release.

    Checkout the Vector Log Shipping docs for more usage information.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#golang-plugin-rewrites","title":"Golang Plugin Rewrites","text":"

    A few plugins have been rewritten in Golang:

    Generally speaking, plugins are rewritten when the complexity of writing future features outweighs keeping the plugin implemented in shell code. In particular, any plugins that perform one of the following tasks are good candidates for higher-level languages:

    While all of these have been performed one time or another in bash, the fact is that there are a ton of edge cases that have popped up over the years that make it super difficult to even reason about some of the code, whereas it is fairly easy for me to handle these within Golang (either with the standard library or something off-the-shelf).

    All that said, not all plugins will be rewritten in Golang - the git plugin is likely to stay as is - and some plugins may see hybrid rewrites as necessary, but this should hopefully give folks a bit of an idea as to why the Dokku codebase is not predominantly written in shell.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.22.0 migration guide for more information on upgrading to 0.22.0.

    ","tags":["dokku","release"]},{"location":"2021/dokkus-roaring-20s/#future-development","title":"Future Development","text":"

    0.22.x was a feature-packed release, and we're not slowing down. 0.23.x is around the corner, and will include quite a few interesting features for folks. We'll save those notes for the next blog post :)

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/","title":"Dokku 0.27.x Wrapup","text":"

    Dokku version 0.27.0 was released a few months ago. This post covers the important changes that occurred throughout the lifetime of the 0.27.x series. A future post will cover the 0.28.0 release.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#os-and-architecture-support","title":"OS and Architecture Support","text":"

    Ubuntu Focal was added as a release target. We also added support for ARM (32-bit) and ARM64 architectures. Users on Raspberry Pis should be able to install the latest Dokku, regardless of OS or Architecture.

    Additionally, the Dokku docker image is now based on Focal :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#app-and-service-filtering","title":"App and service filtering","text":"

    It is now possible to filter apps and services via the user-auth-app and user-auth-service triggers. These can be implemented in custom plugins to constrain what a user has access to, and is in use within Dokku Pro for it's team-management system.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#fixes","title":"Fixes","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#app-domain-renames-are-scoped-to-global-domains","title":"App domain renames are scoped to global domains","text":"

    Previously, if you had an app named test with a domain of tester.com and renamed it to test-2, we would rename the domain to test-2er.com. We've now scoped this so app renames only impact domains associated with any global domains on the server.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#remove-bad-intermediate-containers","title":"Remove bad intermediate containers","text":"

    Due to how Dokku handles the build process, intermediate containers reuse the internal docker image name for an app. This means that it is sometimes possible to execute dokku run against an intermediate image.

    Dokku now properly removes intermediate images if the build fails.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#support-for-special-characters-in-docker-container-options","title":"Support for special characters in docker container options","text":"

    Dokku now supports using special characters, such as parenthesis, in container options. Here is an example:

    dokku docker-options:add node-js-app deploy '--label \"some.key=Host(\\`node-js-app.dokku.arketyped.net\\`)\"'\n

    Some characters should be escaped - and quoting matters! - but label-based proxy-implementations can now take full advantage of apps deployed via Dokku.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.27.0 migration guide for more information on upgrading to 0.27.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.27.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    Those were the major changes in 0.27.x. Our next post will cover 0.28.0!

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/","title":"Dokku 0.28.x Wrapup","text":"

    It's wrapup time! This post covers the important changes that occurred throughout the lifetime of the 0.28.x series.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#removals","title":"Removals","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#no-more-support-for-centos-7-debian-9-fedora-opensuse","title":"No more support for Centos 7, Debian 9, Fedora, OpenSuse","text":"

    With the maturation of our Docker-based deployment offering, we've removed official support for these other operating systems.

    Why would we do this? For Centos, Fedora, and OpenSuse, they were simply untested integrations that were half-baked into Dokku over the years. Worse, we only ever built a package for Centos, and never actually guaranteed support for the others.

    As far as Debian 9 is concerned, the OS reached end-of-life in July of 2022, and it only makes sense to drop support for something unsupported upstream.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#deprecations","title":"Deprecations","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#ubuntu-1804-is-deprecated","title":"Ubuntu 18.04 is deprecated","text":"

    Ubuntu 18.04 is now a deprecated installation target. The operating system will be considered EOL by Canonical in April 2023. Users are encouraged to upgrade to Ubuntu 22.04 or consider switching their installation method to the Docker-based installation method to avoid any disruption in usage.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#additions","title":"Additions","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#the-automatic-init-process-can-now-be-disabled","title":"The automatic init process can now be disabled","text":"

    This change allows projects using s6 overlay - in particular linxserver images - the ability to disable --init flag injection.

    Additionally, force-disable --init flag usage for all linuxserver images. Linuxserver images uses S6, and there are enough of them that this makes sense to autodetect on behalf of users.

    Users should be able to more easily deploy s6-based images, whether they are official Linuxserver ones or images they've built on their own :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#new-proxy-implementations","title":"New Proxy Implementations","text":"

    As we've grown, the nginx plugin has seen a few warts. Notably, it doesn't tightly integrate with Docker, which sometimes causes requests to either route to the wrong container or fail when the container changes IP address. Additionally, our Letsencrypt integration on top of it is a bit of a hack.

    As a result, we've decided to create official alternative proxy integrations to our existing nginx plugin. The first two are caddy and traefik, both of which boast healthy development processes and have great integrations with Docker-based deployment environments. In a future release, we also hope to add an official haproxy plugin, and may revisit our nginx integration as well.

    Please note that none of this means we're dropping support for our existing nginx integration. Users should feel comfortable depending on nginx, switching only as needed.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#an-official-caddy-proxy-implementation","title":"An official caddy proxy implementation","text":"

    This plugin uses a docker-compose based Caddy installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    One big change is that requests are routed as soon as the container is running and passing healthchecks.

    Checkout the official caddy integration documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#an-official-traefik-proxy-implementation","title":"An official traefik proxy implementation","text":"

    While Caddy is great, some folks may wish to pursue deeper, Traefik-based integration instead. Unlike Caddy, Traefik provides native integration with many schedulers, providing even deeper integration for your routing needs.

    This plugin uses a docker-compose based Traefik installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    Requests are routed as soon as the container is running and passing healthchecks.

    Checkout the official traefik integration documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#a-builder-for-lambda-functions","title":"A builder for lambda functions","text":"

    Dokku has always been a something of a generic workflow tool. Source code comes in, gets built into an artifact, and then can be scheduled.

    With 0.28.x, we've introduced a new builder-lambda plugin. This plugin emulates the lambda build process, generating both a runnable docker image and a tarball that is compatible with AWS Lambda. We hope to bring an AWS Lambda-compatible scheduler to Dokku in the near future.

    Checkout the official builder-lambda documentation here!

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#add-support-for-devcontainers-on-arm64-instances","title":"Add support for devcontainers on ARM64 instances","text":"

    Lots of developers - including myself! - are moving to M1/M2 MacOS installations, and development of Dokku must continue. The 0.28.x series adds support for using VSCode Devcontainers on ARM64 instances, allowing development to continue unabated.

    Truthfully, this is somewhat selfish as my main driver had to change - RIP my Intel Mac - but hopefully others contributing to Dokku also benefit :)

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#fixes","title":"Fixes","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#set-corebaretrue-on-correct-repository-path","title":"Set core.bare=true on correct repository path","text":"

    When deploying a project via git:sync, it was possible to get into a state where your repo was no longer able to have git push executed against it. This change fixes that, so folks can initialize apps via git:sync for the first time and then git push afterwards.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#ignore-https-mappings-when-no-ssl-certificate-exists","title":"Ignore https mappings when no ssl certificate exists","text":"

    This fixes issues where users may somehow add an https mapping but are missing an ssl certificate, causing nginx to not load properly. We now ignore the mapping and warn users of the misconfiguration.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.28.0 migration guide for more information on upgrading to 0.28.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.28.x-wrapup/#its-a-wrap","title":"It's a wrap","text":"

    Those were the major changes in 0.28.x. Our next post will cover 0.29.0!

    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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/","title":"Dokku Release 0.29.0","text":"

    The last minor release of the year is here! Here is a summary of what is new in 0.29.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#changes-in-029x","title":"Changes in 0.29.x","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#file-extraction-moved-from-image-to-repository","title":"File extraction moved from image to repository","text":"

    Previously, Dokku would build the app image - via whichever builder was specified - and then extract files from the built image. This allowed some level of customization of certain files - such as generating a Procfile or nginx.conf.sigil during the build process based on environment variables. However, the logic is a bit contrary to how we handle other files in mono-repo setups.

    With 0.29.x, we now extract files from the repository source code where possible. This allows our monorepo codebase handling to act the same everywhere and also speeds up app builds.

    Note

    The current notable exception to the new extraction process is the app.json file, which will be fixed in the next minor release.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#app-domains-are-now-setup-at-app-creation-time","title":"App domains are now setup at app creation time","text":"

    Previously, domains were attached to apps when proxy configuration was first generated. This caused issues when domains were referred to prior to the first app deploy. Dokku will now instead associate app domains on app creation, and users may later remove the domains as desired.

    One side effect of this is the refactor of how domains and app urls are referred to within Dokku. Please see the migration guide for more details how how this might impact your usage of Dokku.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#new-in-029x","title":"New in 0.29.x","text":"","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#run-subcommand-additions","title":"run subcommand additions","text":"

    We've added a few new commands to the built-in run plugin:

    We've also added JSON output support for the run:list command, making it easier to manipulate in a programmatic manner.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#initial-herokuish-support-on-arm-servers","title":"Initial herokuish support on ARM servers","text":"

    While Dokku has supported ARM/ARM64 servers for a while, Herokuish - the most common builder in use with Dokku - has not. While it is possible to make a buildpack ARM-compatible, the majority are not, and thus we blocked off the functionality to avoid causing issues for users.

    For more adventurous Dokku users, the herokuish builder can now be enabled on ARM/ARM64 servers (though it is not enabled by default). Individual buildpacks will still need to have support added for ARM/ARM64 platforms, but users are no longer artificially limited by Dokku to other builders.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.29.0 migration guide for more information on upgrading to 0.29.0.

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2022/dokku-0.29.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 8 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2022/pro-release-1.1.0/","title":"Pro release 1.1.0","text":"

    The 1.1.0 release is the first substantive update to Dokku Pro, and it brings with it great changes around usability and functionality.

    Get your copy today

    Dokku Pro was released in late 2021 to early bird users willing to deal with a bit of pain in exchange for supporting the project and vision. While it technically worked, there were quite a few places for easy improvement, as well as obvious holes in the existing functionality. Dokku Pro 1.1.0 aims to fill some of those needs, laying the groundwork for future enhancements.

    Here are a few of the updates included in Dokku Pro 1.1.0.

    "},{"location":"2022/pro-release-1.1.0/#major-changes","title":"Major Changes","text":""},{"location":"2022/pro-release-1.1.0/#this-lovely-docs-site","title":"This lovely docs site","text":"

    We've added a more comprehensive documentation site for Dokku Pro. The documentation will continue to improve and will always reference the latest version of Dokku Pro (currently 1.1.0). Enjoy!

    "},{"location":"2022/pro-release-1.1.0/#requires-dokku-0270","title":"Requires Dokku 0.27.0","text":"

    The minimum Dokku version increase was made to ensure memory-scaling worked properly. Users of older version of Dokku may still have working installs, though memory scaling will not work correctly for the docker-local scheduler.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.1.0/#minimum-required-datastore-plugin-versions","title":"Minimum required datastore plugin versions","text":"

    As a reminder, it is also recommended to update all datastore plugins to ensure services are properly listed in the API and UI. In addition, the upgrades are necessary for support for deferred app rebuilds during service linking. Without them, service linking may time out.

    Here are the versions necessary for this release of Dokku Pro:

    Plugin Version clickhouse 0.13.3 couchdb 1.21.4 elasticsearch 1.20.3 graphite 1.18.2 mariadb 1.19.2 meilisearch 0.2.1 memcached 1.18.4 mongo 1.17.4 mysql 1.19.4 nats 1.19.3 omnisci 1.19.1 postgres 1.19.3 pushpin 0.9.1 rabbitmq 1.19.4 redis 1.19.2 rethinkdb 1.17.2 solr 1.19.4

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.1.0/#add-ability-to-link-an-app-to-a-service","title":"Add ability to link an app to a service","text":"

    Users are now able to link apps to services. This required a ton of changes to how datastores worked in the API, and the resulting refactor makes it much easier to add new datastores to Dokku Pro.

    To manage service links, go to the Settings section of a given app and use the Linked Services subsection.

    UI for managing service links"},{"location":"2022/pro-release-1.1.0/#refactor-datastore-and-service-apis-for-easier-expansion","title":"Refactor datastore and service apis for easier expansion","text":"

    In order to make service linking work, we required a few changes:

    Dokku Pro 1.1.0 brings a simplified /datastores and /services api. The former is used to interact with the datastore plugins as a whole - in the future, this may even include setting global datastore plugin properties. The /services endpoint now abstracts all instances of every datastore, bringing a single api endpoint for querying and interacting with all services installed on your Dokku server. This makes it much simpler to support a new datastore - now a 2-line change - versus the previous method of generating various files that still needed work to plug into the api model layer.

    These APIs are now considered stable for external use. Enjoy!

    "},{"location":"2022/pro-release-1.1.0/#implement-resource-scaling-ui","title":"Implement resource scaling ui","text":"

    The initial release of Dokku Pro included process count scaling, but offered nothing for container resources. New in 1.1.0, we added the ability to set memory reservations.

    Memory scaling

    For this rough release, we've opted to avoid limits - so that containers can burst on resource utilization - and have omitted CPU - as this is typically bursty on single-instance Dokku installations. We'll be working on the UI in future releases, and hope to include both memory and CPU for limits and reservations in a way that makes sense for our users.

    See this tweet thread for more details on how... interesting this functionality ended up.

    "},{"location":"2022/pro-release-1.1.0/#add-swagger-support","title":"Add swagger support","text":"

    An interactive Swagger UI for Dokku Pro is now available at the /swagger endpoint. Users can also access the OpenAPI 3.0.1 spec at /swagger/openapi.yml.

    Integrated Swagger UI"},{"location":"2022/pro-release-1.1.0/#add-ability-to-set-the-scheduler-on-a-per-app-basis","title":"Add ability to set the scheduler on a per-app basis","text":"

    We've added the ability to set an app scheduler on a per-app basis. This automatically picks up the following schedulers (if installed) and displays them for selection:

    Selection a non-standard scheduler"},{"location":"2022/pro-release-1.1.0/#minor-changes","title":"Minor Changes","text":""},{"location":"2022/pro-release-1.1.0/#allow-customizing-the-network-dokku-pro-listens-on","title":"Allow customizing the network dokku-pro listens on","text":"

    If you are running Dokku Pro on a local network that doesn't have IPv6 support, you can now set the SERVER_NETWORK configuration variable to tcp4 to listen only on IPv4.

    "},{"location":"2022/pro-release-1.1.0/#set-higher-default-write-timeout-to-allow-for-slow-service-creation-calls-to-complete","title":"Set higher default write timeout to allow for slow service creation calls to complete","text":"

    The default server read and write timeouts were too low for certain tasks - notably datastore creation and destruction - to complete in time, resulting in UI errors. These are now configurable via SERVER_READ_TIMEOUT and SERVER_WRITE_TIMEOUT, and also have higher default values. Folks on slower servers should see significant improvement in their overall user experience.

    "},{"location":"2022/pro-release-1.1.0/#add-cli-command-for-outputting-current-dokku-pro-settings","title":"Add cli command for outputting current dokku-pro settings","text":"

    One annoying issue when debugging an installation is ensuring all the configuration variables are set properly. Users can now run dokku-pro config to show a user-friendly version of the current server config. This can be used to verify that the Dokku Pro license and other configuration options are as you expect.

    "},{"location":"2022/pro-release-1.1.0/#ui-changes","title":"UI Changes","text":""},{"location":"2022/pro-release-1.1.0/#always-use-correct-icon-size-for-app-status","title":"Always use correct icon size for app status","text":"

    The app status icon was sometimes too large. While big head mode is cool, its not so much in a UI. We now use the correct image size.

    "},{"location":"2022/pro-release-1.1.0/#fix-issue-in-ui-when-saving-a-domain-for-an-app","title":"Fix issue in ui when saving a domain for an app","text":"

    Apps with no domains had issues saving an initial domain without using the CLI. Since one of the goals of Dokku Pro is to supply a web UI, this seems a bit backwards. You can now properly set domains for new apps!

    "},{"location":"2022/pro-release-1.1.0/#correct-process-type-name-in-the-scaling-ui","title":"Correct process type name in the scaling UI","text":"

    The process scaling ui showed the app name instead of the process type. This made no sense and was confusing for users with multiple process types.

    "},{"location":"2022/pro-release-1.1.0/#make-the-envdomains-settings-pages-span-the-entire-page","title":"Make the env/domains settings pages span the entire page","text":"

    There was a minor change to the environment variable and domain setting pages that made better use of the screen real estate.

    "},{"location":"2022/pro-release-1.1.0/#api-changes","title":"API Changes","text":""},{"location":"2022/pro-release-1.1.0/#add-meilisearch-datastore-plugin","title":"Add meilisearch datastore plugin","text":"

    Taking advantage of our new datastore plumbing, we added the Meilisearch plugin to Dokku Pro.

    "},{"location":"2022/pro-release-1.1.0/#add-better-error-messaging-when-validating-api-entities-from-composite-keys","title":"Add better error messaging when validating api entities from composite keys","text":"

    When interacting with entities that have composite primary keys - domains, environment variables, formations - users would get somewhat opaque error messages. These have been updated to include more detail.

    "},{"location":"2022/pro-release-1.1.0/#fix-access-to-service-relationships-in-the-api","title":"Fix access to service relationships in the api","text":"

    Services now come back as properly associated with apps, making many of the normal json-api relationship endpoints work.

    "},{"location":"2022/pro-release-1.1.0/#dokku-pro-pricing","title":"Dokku Pro Pricing","text":"

    Now that there is a new release of Dokku Pro, the early bird pricing will increase. This was previously mentioned in various Dokku Pro announcements, but the price will continue to increase by various amounts until the product settles.

    Please bear in mind that this is a lifetime license, and users are entitled to all upgrades of Dokku Pro as long as they are made. Folks wishing to support continued development of the project are encouraged to purchase today before the price is increased.

    Get your copy today

    "},{"location":"2022/pro-release-1.1.0/#coming-up-next","title":"Coming up next?","text":"

    The next milestone will continue to have many minor additions, with some effort made on the following additions:

    As always, the roadmap is always subject to change, pending time constraints but mostly feature requests by those who have purchased Dokku Pro. Have a feature request or bug complaint? Feel free to file it in the issue tracker here.

    Thanks everyone for there support during this endeavor, and I hope you all enjoy this release of Dokku Pro!

    "},{"location":"2022/pro-release-1.2.0/","title":"Pro release 1.2.0","text":"

    The 1.2.0 release introduces team-based access control and many internal refactors aimed at easing future development of the product.

    Get your copy today

    Dokku has traditionally been a single-tenant PaaS solution, where all users had access to all functionality on the server. While there were community plugins that tackled authentication, each implementation had it's rough edges due to interfaces in Dokku itself. Dokku Pro 1.2.0 polishes those edges while introducing a flexible permission system for organizations that need it.

    Here are a few of the updates included in Dokku Pro 1.2.0.

    "},{"location":"2022/pro-release-1.2.0/#major-changes","title":"Major Changes","text":""},{"location":"2022/pro-release-1.2.0/#requires-dokku-0278","title":"Requires Dokku 0.27.8+","text":"

    Warning

    Dokku Pro 1.2+ will refuse to start if the minimum Dokku version is not installed.

    The minimum Dokku version increase was made to support new functionality in Dokku Pro. The previous 1.1.0 version required at least 0.27.0, so hopefully this upgrade does not cause too many issues for folks.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#minimum-required-service-plugin-versions","title":"Minimum required service plugin versions","text":"

    Warning

    Dokku Pro 1.2+ will refuse to start if an installed plugin is not at the minimum supported version.

    As a reminder, it is also recommended to update all service plugins to ensure services are properly listed in the API and UI. In addition, the upgrades are necessary for support for deferred app rebuilds during service linking. Without them, service linking may time out.

    Certain new functionality in Dokku Pro required changes to the service plugins.

    Here are the versions necessary for this release of Dokku Pro:

    Plugin Version clickhouse 0.17.0 couchdb 1.25.0 elasticsearch 1.24.0 graphite 1.22.0 mariadb 1.24.0 meilisearch 0.6.0 memcached 1.22.0 mongo 1.21.0 mysql 1.23.0 nats 1.24.0 omnisci 1.23.0 postgres 1.24.0 pushpin 0.14.0 rabbitmq 1.24.0 redis 1.24.0 rethinkdb 1.21.0 solr 1.24.0 typesense 1.5.0

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#new-apis-for-community-plugins","title":"New APIs for community plugins","text":"

    Two plugins were added to Dokku Pro's HTTP API. API Support for Dokku features generally comes first, while later releases will include changes to the Web UI to include these additions.

    "},{"location":"2022/pro-release-1.2.0/#api-support-for-the-community-http-auth-plugin","title":"API support for the community HTTP Auth Plugin","text":"

    Authentication comes in many forms, and while most apps have this built-in, simpler, pre-packaged applications may not. Dokku Pro introduces support for the community http-auth plugin, with full API support for managing both user-based and IP-based access controls. This comes with documentation in our included Swagger UI.

    A future release of Dokku Pro will include a section in the UI for managing network components for apps, including HTTP Auth support.

    "},{"location":"2022/pro-release-1.2.0/#api-support-for-the-community-http-auth-plugin_1","title":"API support for the community HTTP Auth Plugin","text":"

    In addition to authentication requirements, it may be necessary to enable or disable all access to your application. The community maintenance plugin provides the ability to do just that.

    In this release, we've added the ability to enable or disable maintenance mode via API, fully-documented within our included Swagger UI. A future release of Dokku Pro will include a section in the UI for managing network components for apps, including setting apps in maintenance mode.

    "},{"location":"2022/pro-release-1.2.0/#add-ability-to-set-the-builder-on-a-per-app-basis","title":"Add ability to set the builder on a per-app basis","text":"

    We've added the ability to set an app builder on a per-app basis. This automatically picks up the following builders (if installed) and displays them for selection:

    Selection a non-standard builder

    It is also possible to set a custom build directory in the same UI.

    Selection a non-standard builder

    Both of these include API access, documented in our included Swagger UI.

    "},{"location":"2022/pro-release-1.2.0/#team-management","title":"Team Management","text":"

    Access control is a complex topic, and one Dokku has traditionally shied away from. Dokku does not have a traditional user model, and it associates a simple name to each ssh-key that a user uses to interact with the CLI over SSH. Until recently, the only way to limit access was by installing the community dokku-acl plugin and hoping it's rigid model for checking permissions aligned with how you wanted to expose server access.

    With Dokku Pro 1.2.0, there is now a flexible team-based model for access control. System administrators can continue to access everything, but may create teams with permissions against particular apps, services, and commands. Owners - such as team leads or project managers - can be assigned to teams, delegating access control for those teams to the folks closest to what those teams represent. And finally, team members can perform the commands allowed by their team permissions against the apps and services those teams control, and nothing more.

    The development of this feature required changes across the Dokku ecosystem. New triggers were exposed in both service plugins as well as Dokku itself to manage filtering of apps and services, while some plugins had to be updated in order to respect the updated command system. Dokku Pro itself had several changes to the permissioning system as it was designed and tested in real world settings. While the initial intent was to release Dokku Pro much more often, the work behind team management hopefully makes the wait worth it.

    The initial release of team management is available via CLI commands. This decision was made in order to release Dokku Pro sooner. A future release of Dokku Pro will include API support for team management as well as Web UI integration for managing teams.

    Checkout the team management documentation for more information on how team-based access control works.

    "},{"location":"2022/pro-release-1.2.0/#minor-changes","title":"Minor Changes","text":"

    Some of the more minor changes were made to make development of Dokku Pro itself much more pleasant. Rather than having a \"miscellaneous bug fixes and improvements\" section as you'd see in many other public product release notes, we'll outline them below.

    "},{"location":"2022/pro-release-1.2.0/#updated-dependencies","title":"Updated Dependencies","text":"

    Dokku Pro uses a ton of code itself. We've started the efforts to get the server-side code up to date in an automatic fashion, and are ramping up efforts to modernize the Web UI as well.

    "},{"location":"2022/pro-release-1.2.0/#filtering-apps-in-dokku-pro","title":"Filtering apps in Dokku Pro","text":"

    For some use-cases, it may be necessary to hide some apps from the Web UI and API. In the case of Dokku's own installation of Dokku Pro, there are some testing apps that have no value other than being placeholders for requests, and thus are noise in the UI.

    It is now possible to filter such apps from being accessible via Dokku Pro's interface (they will still be available via CLI using normal dokku commands). An APPS_FILTER environment variable can be set in the Dokku config with a comma-delimited list of apps to hide. These apps will be hidden from API responses and the Web UI as a result.

    Checkout the configuration documentation for more information on this new setting.

    "},{"location":"2022/pro-release-1.2.0/#ability-to-override-the-default-root-username","title":"Ability to override the default root username","text":"

    While the password for authentication is configurable, the root username was not. An ROOT_USERNAME can be set in the Dokku config to override the default root username. You can now login as the lollipop user if desired.

    Checkout the configuration documentation for more information on this new setting.

    "},{"location":"2022/pro-release-1.2.0/#typesense-service-support","title":"Typesense service support","text":"

    Support for the new typesense plugin has been added to services in Dokku. Users can expect the same functionality they would from other services in Dokku, including complete support in our API, Swagger UI documentation, and exposure in the Web UI.

    New services will be added to future Dokku Pro releases as they are made available.

    "},{"location":"2022/pro-release-1.2.0/#version-checking-for-server-commands","title":"Version checking for server commands","text":"

    As mentioned above, we now check for specific versions of Dokku and installed plugins on start of the Dokku Pro server. Users wishing to use supported plugins that do not have at least the minimum version specified will have Dokku Pro fail to boot with an error message detailing the problem.

    Please be sure to keep up to date with the latest and greatest versions of Dokku and any plugins you use.

    To update, run:

    # update the ``dokku-update` package first\nsudo apt update\nsudo apt install dokku-update\n\n# update your install (skipping app rebuild)\nsudo dokku-update run --skip-rebuild\n
    "},{"location":"2022/pro-release-1.2.0/#enhanced-output-for-the-config-command","title":"Enhanced output for the config command","text":"

    When running the dokku-pro config command, we previously hardcoded how certain config was output. This has been refactored in such a way that we no longer need to update the config command when adding new configuration properties.

    "},{"location":"2022/pro-release-1.2.0/#fix-log-formatting","title":"Fix log formatting","text":"

    Log output was a bit broken for the help and version commands, and elsewhere. Dokku Pro now will only log in JSON format when there is no TTY - for example, when running under systemd - and will have human-readable output otherwise

    Additionally, we now use a single logging mechanism across the codebase, ensuring most - if not all - logs are in the proper format, regardless of where the log call is created.

    "},{"location":"2022/pro-release-1.2.0/#ignoring-compiled-assets-during-project-search","title":"Ignoring compiled assets during project search","text":"

    This was actually a fairly painful issue, workflow-wise. Searching for instances of code during refactoring was made painful due to including compiled assets, binary files, and external dependencies. These are now ignored so the editor does not lock up when searching for a random bit of javascript :)

    "},{"location":"2022/pro-release-1.2.0/#standardized-code-initialization","title":"Standardized code initialization","text":"

    Previously, Dokku Pro would set up certain checks and load config on-the-fly. This led to race conditions in certain cases, and was messier to understand. All initialization code has now been placed in a central location that is easy to understand when first diving into the code.

    "},{"location":"2022/pro-release-1.2.0/#dokku-pro-pricing","title":"Dokku Pro Pricing","text":"

    With a new release comes a price increase. Although it was mentioned in the 1.1.0 release post, we previously avoided a price increase to give folks more time to consider supporting Dokku Pro development at a lower price point. With the new functionality, we believe it is time to start the increases. Dokku Pro's price will continue to increase over time by various amounts until the product settles to a more \"feature-complete\" state.

    Please bear in mind that this is a lifetime license, and users are entitled to all upgrades of Dokku Pro as long as they are made. Folks wishing to support continued development of the project are encouraged to purchase today before the price is increased.

    Get your copy today

    "},{"location":"2022/pro-release-1.2.0/#coming-up-next","title":"Coming up next?","text":"

    Here is what we'll be working towards over the next few releases

    As always, the roadmap is always subject to change, pending time constraints but mostly feature requests by those who have purchased Dokku Pro. Have a feature request or bug complaint? Feel free to file it in the issue tracker here.

    Thanks everyone for there support during this endeavor, and I hope you all enjoy this release of Dokku Pro!

    "},{"location":"2023/dokku-0.30.0/","title":"Dokku Release 0.30.0","text":"

    The first minor release of the year is here! Here is a summary of what is new in 0.30.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#removals-in-030x","title":"Removals in 0.30.x","text":"

    The following functionality has long been deprecated and is now removed:

    We also removed a ton of deprecated commands and functions across dokku in #5659.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#changes-in-030x","title":"Changes in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#eol-of-ubuntu-1804-support","title":"EOL of Ubuntu 18.04 support","text":"

    With upstream dropping LTS support, Ubuntu 18.04 support in Dokku is EOL. Users are heavily encouraged to upgrade their operating systems to Ubuntu 20.04 or Ubuntu 22.04, either via an upgrade or fresh install. The next release of Dokku will stop releasing for Ubuntu 18.04 and packages will be removed in the future.

    Please note that while our existing packages may continue to run on Ubuntu 18.04, issues for those running on 18.04 may be summarily closed.

    Finally, Herokuish will also shortly drop Ubuntu 18.04 releases. Users are heavily encouraged to upgrade their apps to newer stacks, as those apps may fail to build for a variety of reasons.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#appjson-extraction-moved-from-image-to-repository","title":"app.json extraction moved from image to repository","text":"

    In 0.29.x, we moved file extraction for various supporting files from the built image to the app source. This change now also applies to app.json. This was done in order to standardize how mono-repo codebases were built.

    With 0.30.x, we now extract app.json from the repository source code where possible. This allows our monorepo codebase handling to act the same everywhere and also speeds up app builds.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#new-in-030x","title":"New in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#an-official-haproxy-proxy-implementation","title":"An official haproxy proxy implementation","text":"

    This plugin uses a docker-compose based Haproxy installation in conjunction with injected container labels to route requests. It only exposes the minimal necessary for routing traffic to docker containers. Users wishing to customize further labels may explore using the docker-options plugin to attach additional labels during the 'deploy' phase.

    Big thanks to @byjg for their work on EasyHAProxy

    Checkout the official haproxy integration documentation here!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#simplified-image-deployment-via-gitload-image","title":"Simplified image deployment via git:load-image","text":"

    Similar to git:load-image - and using the same internal infrastructure to manage history - there is a new git:load-image command. This new command supports deploying the output of docker image save $IMAGE_NAME on stdin, keeping git history with every deploy.

    The git:load-image command is meant to be used in cases where the deployment model is to deploy from a built docker image in CI. This is useful when users do not have an intermediate docker registry available from which they can deploy.

    See the git documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#interacting-with-multiple-dokku-remotes-via-the-official-client","title":"Interacting with multiple dokku remotes via the official client","text":"

    In some cases, users may deploy a given repository to multiple Dokku apps. This is especially useful when deploying to pre-production environments or using review apps. The official client now supports a series of remote subcommands that allow users to manage remotes for a local repository.

    See the remote client documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#nginx-proxy-rebuilds-early-to-avoid-downtime","title":"Nginx proxy rebuilds early to avoid downtime","text":"

    In a previous release, we moved the web process to be deployed first. This allowed folks to quickly see errors on their mainline process, vs seeing those near the end. The end result, however, made it so that apps with large numbers of process types had downtime as the old web containers were removed after a minute if the app also used nginx as it's proxy layer. Users of other proxy implementations - such as Caddy, Haproxy, and Traefik - are not affected by this bug.

    We now trigger an early rebuild of the nginx config for users utilizing the nginx proxy implementation. Concerned users should switch to other proxy implementations to be completely unaffected by this change.

    Note that a future release of Dokku will also provide an optional nginx-proxy layer based on labels similar to our other proxy implementations. This will avoid long-standing downtime issues and hopefully allow us to be more flexible in how applications can be proxied. See the nginx-docker-proxy project for more details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#avoid-reinstalling-plugins-in-the-provided-dokku-docker-image","title":"Avoid reinstalling plugins in the provided Dokku docker image","text":"

    We now no longer attempt to reinstall plugins that already exist. This fixes issues for users that specify plugins via a plugin-list versus installing directly to the docker image via a custom Dockerfile.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#fix-pack-entrypoint-support","title":"Fix pack entrypoint support","text":"

    A recent change in CNB's pack utility changed how processes were launched, causing any process to fail to start. We now specify a custom entrypoint to fix this issue. Users of CNB can get back to building their apps!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.30.0 migration guide for more information on upgrading to 0.30.0.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.30.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 7 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/","title":"Dokku Release 0.31.0","text":"

    The second release of the year is here! Here is a summary of what is new in 0.31.x.

    Tip

    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.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#deprecations","title":"Deprecations","text":"

    To start, there are a few features that are now deprecated in Dokku.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#arm-not-arm64-support-is-deprecated","title":"ARM (not ARM64!) support is deprecated","text":"

    Our build process around ARM is fairly flaky - breaking CI more often than not - and the resulting docker image/debian packages are not actually tested. As a result, we're going to remove support for the platform in the next release, and recommend users upgrade their operating systems to ARM64 where possible.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#deprecation-of-the-checks-file","title":"Deprecation of the CHECKS file","text":"

    This file is now deprecated in favor of the new healthchecks functionality in app.json - more on that later - and users should begin migrating today. The docker-container-healthchecker tool can be used to convert a CHECKS file into the correct format for app.json usage. We expect to remove CHECKS support in a future release (likely 0.32.x).

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#proxyports-commands-are-deprecated","title":"proxy:ports-* commands are deprecated","text":"

    The proxy:ports-* commands are deprecated in favor of the new ports plugin - more on that later - users should adjust their workflows appropriately. The deprecation is occuring it was quite common for users to set port mappings incorrectly via proxy:set, thus breaking routing. Rather than keep the old commands around, we're going to nix it completely.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#changes-in-031x","title":"Changes in 0.31.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#heroku-22-is-the-new-default","title":"heroku-22 is the new default","text":"

    Dokku now tracks Ubuntu 22.04 for it's default builders. What does this mean?

    Users can still switch their base images via the command appropriate for their builder :)

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#herokuish-builds-now-use-volumes-for-cache","title":"Herokuish builds now use volumes for cache","text":"

    Previously, Herokuish builds would mount a directory on disk for build-time file caching. This worked mostly fine, but was an issue for a few reasons:

    Dokku now uses a docker volume for herokuish build cache - similar to how Cloud Native Buildpacks treat cache - which greatly simplifies cache management.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#new-in-030x","title":"New in 0.30.x","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#an-official-openresty-proxy-implementation","title":"An official openresty proxy implementation","text":"

    This plugin uses a docker-compose based OpenResty installation in conjunction with injected container labels to route requests. It supports all properties supported by the nginx plugin, and includes built-in Letsencrypt support. Over time, we intend to make further improvements to this plugin and place the nginx plugin in a general maintenance mode. Users are encouraged to try out the OpenResty plugin to see if it meets their needs.

    Big thanks to OrcaScan for sponsoring the work on OpenResty!

    Checkout the official openresty integration documentation here.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#improved-healthchecking-support-via-appjson","title":"Improved healthchecking support via app.json","text":"

    The pre-existing healthcheck support in Dokku was fairly limited:

    All of these - and more - are solved by the new healthchecks support in the app.json file. Users can now specify one or more customized uptime checks, arbitrary command checks, as well as http checks (with more functionality!) for any process type.

    {\n  \"healthchecks\": {\n    \"web\": [\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"web check\",\n            \"description\": \"Checking if the app responds to the /health/ready endpoint\",\n            \"path\":        \"/health/ready\",\n            \"attempts\": 3\n        }\n    ],\n    \"worker\": [\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"uptime check\",\n            \"description\": \"Checking if the container is up for at least 10 seconds\",\n            \"uptime\":      10\n        },\n        {\n            \"type\":        \"startup\",\n            \"name\":        \"command check\",\n            \"description\": \"Checking if a command in the container runs as expected\",\n            \"timeout\":     5,\n            \"attempts\":    5,\n            \"wait\":        10,\n            \"command\":     [\"/app/script.sh\"]\n        }\n    ]\n}\n

    Note

    Support for individual healthcheck properties is provided by individual schedulers, and not guaranteed to work the same across all schedulers. In particular, only the docker-local scheduler supports content checks for http requests.

    Dokku will convert all CHECKS files into the app.json format until support for that file format is removed, and users can use the docker-container-healthchecker tool to migrate to the new format.

    While we only support startup checks - checks that happen during container start at deploy time - in the future, Dokku will also support readiness and liveness checks in the future for it's docker-local scheduler.

    See the zero downtime deploy checks documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#dokku-cron-improvements","title":"Dokku Cron Improvements","text":"

    For the docker-local scheduler, the crontab generation has been sped up tremendously. Deploys on installations with many apps should be much quicker as cron tasks for each app are generated in parallel vs serially as had been the case.

    The cron:list command now has json output via the --format json option. This can help those integrating Dokku with other systems - such as Ansible modules.

    Finally, cron tasks can now be executed on the fly via the cron:run command. This takes a cron-id - retrievable from the cron:list command - and happens inline by default. They can also be invoked in a detached manner, allowing cron tasks to be run by dispatch.

    See the cron documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#environment-variables-are-available-for-use-with-dockerfile-based-builds","title":"Environment variables are available for use with Dockerfile-based builds","text":"

    Previously, a user wanting to use an environment variable during a build would have to specify the environment variable twice - once for run-time via config:set and once for build-time via docker-options:add. This was error prone as it was easy to fat finger a value, allowed for configuration drift, and made it more annoying to paste the output of dokku report for an app.

    Dokku now automatically exports all environment variables during Dockerfile build. Users can simply specify --build-arg SOME_ENV_VAR docker option to pull in the desired environment variable.

    See the dockerfile builder documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#multi-network-apps","title":"Multi-network apps","text":"

    Dokku has long had support for attaching apps to networks at different phases of an app lifecycle, but could only ever use a single network for each phase. This works well enough for simple architectures, but folks wanting more isolation between applications and datastores might want to place each in a different network and then join them as desired for inter-service communication.

    Dokku now supports specifying multiple, comma-separated networks at each phase. Users can enjoy network isolation support and more easily deploy advanced topologies with the docker-local scheduler, allowing them to mimic what might be the case in production.

    See the network documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#more-robust-port-handling-via-the-new-ports-plugin","title":"More robust port handling via the new ports plugin","text":"

    Dokku's port management has long been confusing:

    Dokku 0.31.x introduces a new ports plugin, reducing a ton of complexity around how port mappings are managed. The new plugin centralizes a lot of the port management code, resulting in a removal of a few port-related network triggers, some environment variables, and more.

    Additionally, Dokku now has \"detected\" port mappings that are fetched on a per-build basis. Users can override the port mapping as necessary, and Dokku will respect any overrides - or allow you to go back to the detected defaults! This makes it easy to ignore ports that are EXPOSEd in a Dockerfile or even use an alternate mapping for buildpack deploys.

    The new ports plugin fixes several long-standing issues in port management in Dokku, and hopefully simplifies port interactions for all of our users.

    See the port management documentation for further details.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#bug-fixes","title":"Bug Fixes","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#server-restarts-do-not-start-all-proxy-implementations","title":"Server restarts do not start all proxy implementations","text":"

    Dokku previously started a container for each proxy implementation, even when not in use. These are now properly tracked, and users will not see Dokku start the containers unless the user has explicitely run the :start subcommand.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#the-source-image-git-property-is-now-cleared-when-changing-deployment-methods","title":"The source-image git property is now cleared when changing deployment methods","text":"

    Previously, this property was left alone, resulting in Dokku not respecting the new source for extracting files for use in the deploy (such as app.json). Dokku will now properly handle this when the deployment method changes (such as when going from image-based to git push), greatly simplifying the process for our users who are experimenting with Dokku.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#traefik-integration-now-runs-correctly-when-running-on-arm64","title":"Traefik integration now runs correctly when running on ARM64","text":"

    Previously, users on ARM64 machines would not be able to enable traefik's letsencrypt integration due to a docker bug in file mounting. This is now fixed across all platforms - simply run traefik:stop and traefik:start.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#upgrading","title":"Upgrading","text":"

    As with every upgrade, please see the 0.31.0 migration guide for more information on upgrading to 0.31.0.

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#future-plans","title":"Future Plans","text":"","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#short-term-project-re-prioritization","title":"Short-term project re-prioritization","text":"

    With the release of Dokku 0.31.0, we've fixed a number of long-standing issues while also implementing a ton of great new features. While development isn't stopping, now is the time to refocus the project a bit for a few reasons:

    With all of the above in mind, the next few months will be spent on enhancing Dokku Pro, implementing long-desired functionality in the official plugins, burning through 1.0 blockers, and bringing the Kubernetes and Nomad scheduler plugins to parity with the built-in docker-local scheduler.

    Is Dokku going away? No. Development will continue unabated, just in other parts of the project. Other than Dokku Pro, no features will be placed behind any paywall, nor will features be removed from the project for any reason. Users can continue to know that Dokku will stay open source, providing a great base for busy developers to get their projects deployed so they can concentrate on building great products.

    We'll still be making releases over the coming months, albeit smaller ones that are more manageable in size. Hopefully the next Dokku release comes out in a month, and not 6 months!

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#dokku-pro","title":"Dokku Pro","text":"

    Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.

    Interested in purchasing Dokku Pro? Dokku Pro is currently provided under early bird pricing (with the price going up as we continue to release new versions). Server licenses are sold in perpetuity, so lock in lower pricing today!

    Purchase Now

    ","tags":["dokku","release"]},{"location":"2023/dokku-0.31.0/#the-next-minor-release","title":"The Next Minor Release","text":"

    Our next release will continue on the 7 outstanding 1.0 issues. 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.

    Tip

    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.

    ","tags":["dokku","release"]}]} \ No newline at end of file diff --git a/blog/sitemap.xml b/blog/sitemap.xml index 783c886bd..2bdbb27fd 100644 --- a/blog/sitemap.xml +++ b/blog/sitemap.xml @@ -2,102 +2,102 @@ https://dokku.com/blog/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2016/resource-management/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2016/welcome-to-dokku/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2018/the-dokku-experience/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2020/comparing-buildpack-v3-to-herokuish/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2020/dokku-0.20.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.23.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.23.x-wrapup/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.24.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.25.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.26.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokku-0.28.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2021/dokkus-roaring-20s/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2022/dokku-0.27.x-wrapup/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2022/dokku-0.28.x-wrapup/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2022/dokku-0.29.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2022/pro-release-1.1.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2022/pro-release-1.2.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2023/dokku-0.30.0/ - 2024-01-07 + 2024-01-16 daily https://dokku.com/blog/2023/dokku-0.31.0/ - 2024-01-07 + 2024-01-16 daily \ No newline at end of file diff --git a/blog/sitemap.xml.gz b/blog/sitemap.xml.gz index f83444f127f3f5bd52e716a2efc122f4599b51ce..3f575a9e4f8efa0a5f758753baf637bd4f8e328e 100644 GIT binary patch delta 354 zcmV-o0iFK!0`>w2ABzYGC8MU12Oodaqyn<*3EBfVFa?Ccu5Chk`=tC49^zsXg)tXc-mW84x-8}@E|jTs*NwE)Jv%8~vy6Yui|btJ ze6OoQaIqykA;~VJ++wS=vXMg#UlzWLO1A1JW2?x5V0XnIJc1`XX2I#vmOy$r$QpVW zJWl8YDg=OdO|Hurm3!tJSa<|325cLS93Yem&ce({8*T$RjjgJTEIV>e=k_*WbvL%I z!3kg5%cO3O=!n(JCsS~T(J3CCd_{e+ z#d^!11bV=EHU%?Q6AKEY1Cr3>IhX<`GrjM3%Fzq|Wvj1`@QYOZ0#Xo>X;KXU0A2H; ACjbBd delta 353 zcmV-n0iOQ$0`&q1ABzYGGgO+92Ood)6Ct~vpgn*CQ$QH(+9ss8uL)7Ywwr3=4R|~n zJ&kQ7veUIw(FLq)bbpK!%Hs(7LYGZn9plfBce0C5`6?T%a^Rzo+`D63dv6YmjpImN zslPGmpU4fNjE&1B6n+S(q7V!)+kvp;4ugMN2N})ZQAbZimLz zIN@`9ITf68jKbt8OkY5FC8JT5W-!R1YxJ#rLoeK*7w%9C9kF`;WD4#uI>ob-Thtd@ zEVukcpnIHWQ!rySv7kUYAPG%ggDG$_)5m_N9KG;gw)*x6zexEnsMoD9QVjqA&!VNH