# History
## 0.29.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.1/bootstrap.sh
sudo DOKKU_TAG=v0.29.1 bash bootstrap.sh
```
### Bug Fixes
- #5532: @josegonzalez Fix issue where git:from-image deploys may result in extracted files not being respected
### Documentation
- #5531: @josegonzalez Fix indentation on heading in where to get help
- #5521: @AlejandroAkbal Remove reference to `--rm` flag cron task documentation
- #5517: @josegonzalez Fix reference to scheduler name in kubernetes docs
- #5516: @josegonzalez Fix reference to scheduler name in nomad docs
### Tests
- #5533: @josegonzalez Add a test case for nested vector-sink values with plus signs
### Other
- #5534: @dependabot[bot] chore(deps): bump sinatra from 3.0.4 to 3.0.5 in /tests/apps/ruby
- #5514: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/go-fail-predeploy
- #5512: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/go-fail-postdeploy
- #5513: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/zombies-dockerfile-no-tini
- #5511: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/zombies-dockerfile-tini
- #5510: @dependabot[bot] chore(deps): bump golang from 1.19.3 to 1.19.4 in /tests/apps/gogrpc
- #5525: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.12 to 11.0.13 in /tests/apps/java
- #5519: @dependabot[bot] chore(deps): bump python from 3.11.0-buster to 3.11.1-buster in /tests/apps/dockerfile-release
- #5520: @dependabot[bot] chore(deps): bump python from 3.11.0-alpine to 3.11.1-alpine in /docs/_build
# History
## 0.29.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.29.0/bootstrap.sh
sudo DOKKU_TAG=v0.29.0 bash bootstrap.sh
```
See the [0.29.0 migration guide](/docs/appendices/0.29.0-migration-guide.md) for more information on migrating to 0.29.0.
### Bug Fixes
- #5506: @josegonzalez Add support for escaped plus (+) signs in vector configurations
- #5505: @josegonzalez Add missing event hooks
- #5493: @josegonzalez Correct issue with detection of non-https port mapping as https port mapping
- #5499: @josegonzalez Do not use traefik priority in service name
- #5491: @josegonzalez Add missing http part to traefik routing rule
- #5477: @josegonzalez Add missing config_sub entry to config gitignore
- #5474: @josegonzalez Add missing source call
- #5345: @esirK Always set app created-at via property instead of introspecting on folder creation time
- #5456: @cooperaj Ensure Traefik only attempts to obtain certificate for api when enabled
- #5466: @josegonzalez Drop the app argument when calling storage:ensure-directory from remote client
- #5458: @cooperaj Ensure the TLS resolver is specifed for HTTPS enabled apps
- #5448: @josegonzalez Do not attempt to attach a network to a container that already has it
### New Features
- #5494: @josegonzalez Silence the warning message when there are no dokku apps on install
- #5490: @josegonzalez Add ability to set a custom priority for traefik routing rules
- #5489: @josegonzalez Use exit code 137 to signify a lock was unable to be retrieved when calling ps:retire
- #5487: @josegonzalez Use a priority when routing requests with traefik
- #5481: @josegonzalez Drop installation of nginx ppa
- #5478: @josegonzalez Allow users to enable herokuish usage on arm/arm64 platforms
- #5479: @josegonzalez Cleanup builder code and docs
- #5476: @josegonzalez Add fileutils plugin to the devcontainer
- #5473: @josegonzalez Add warning when a user is attempting to deploy with an ipv4/ipv6 domain name and has the default nginx site file available
- #5451: @josegonzalez Add git:status subcommand
- #5349: @josegonzalez Error out when executing caddy and traefik commands without the compose plugin installed
- #5322: @josegonzalez Implement run:logs command
- #5321: @josegonzalez Implement run:stop command
- #5434: @josegonzalez Upgrade to go 1.19 everywhere
- #5320: @josegonzalez Add json format output to run:list
### Refactors
- #5488: @josegonzalez De-duplicate proxy building and simplify url generation
- #5454: @josegonzalez Switch from base64-encoding to base36-encoding of cron task IDs
### Documentation
- #5509: @josegonzalez Update data loss blockquote to be warning
- #5507: @josegonzalez Add tutorials link to navigation
- #5503: @josegonzalez Document potential deployment downtime
- #5484: @IgnisDa Add edgedb community plugin
- #5482: @JonathanMH Fixes minor typos in proxy docs
- #5465: @josegonzalez Fix embedded lists on deployment tasks
- #5430: @pablobm Clarify that proxy:build-config is required for any nginx:set call
- #5447: @josegonzalez Specify correct command for builder-lambda:report
- #5429: @pablobm Clarify details of the default template
### Tests
- #5449: @josegonzalez Install goverage via go get
### Other
- #5500: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.3.0 to 3.4.0 in /tests/apps/java
- #5472: @josegonzalez Start started proxies automatically during ps:restore
- #5497: @dependabot[bot] chore(deps): bump ruby from 3.1.2 to 3.1.3 in /tests/apps/dockerfile-entrypoint
- #5496: @dependabot[bot] chore(deps): bump sinatra from 3.0.3 to 3.0.4 in /tests/apps/ruby
- #5480: @josegonzalez Cleanup zero'd out processes when a Procfile omitting those process types is set
- #5475: @josegonzalez Refactor nginx.conf.sigil to be extracted from a specified path in source code instead of the built image
- #5467: @josegonzalez Move DOKKU_WAIT_TO_RETIRE to a checks property
- #5455: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 2.1.0 to 3.0.0
- #5463: @dependabot[bot] chore(deps): bump sinatra from 3.0.2 to 3.0.3 in /tests/apps/ruby
- #5450: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 226 to 227 in /tests/apps/php
- #5437: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/zombies-dockerfile-tini
- #5441: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/gogrpc
- #5440: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/go-fail-predeploy
- #5439: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/zombies-dockerfile-no-tini
- #5438: @dependabot[bot] chore(deps): bump golang from 1.19.2 to 1.19.3 in /tests/apps/go-fail-postdeploy
- #5431: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 225 to 226 in /tests/apps/php
- #5426: @dependabot[bot] chore(deps): bump python from 3.10.0-buster to 3.11.0-buster in /tests/apps/dockerfile-release
- #5319: @josegonzalez Use container name instead of container id for run:detached output
- #5427: @dependabot[bot] chore(deps): bump python from 3.10.8-alpine to 3.11.0-alpine in /docs/_build
The URLS file is no longer necessary as urls are now generated directly from the app VHOST file.
This also moves all the url generation logic to the domains plugin.
This allows us to be backwards compatible when executing git:from-image.
The nice thing about this pattern is we can also extend it to other parts of the deployment as well, such asn nginx-vhosts fetching
This change also moves the referenced Procfile out to a host path once on deploy vs potentially several times, which should speed up deploys a small amount and simplify reasoning about the file.
Closes#5112
While the majority of buildpacks do not work on non-amd64 platforms, this will at least allow developers the option to choose when to override this setting.
The previous method was a bit more difficult for users to interact with as they needed to ensure the file was at a certain path in the built image. This change divorces the file from the built artifact, better aligning the nginx.conf.sigil handling with the rest of Dokku's monorepo support.
A side effect of this is now building proxy configurations does not require access to the built image.
Closes#5207
# History
## 0.28.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.28.4/bootstrap.sh
sudo DOKKU_TAG=v0.28.4 bash bootstrap.sh
```
### Bug Fixes
- #5423: @josegonzalez Respect PLUGIN_PATH when checking if a plugin trigger exists
- #5425: @josegonzalez Ignore https mappings when no ssl certificate exists
### New Features
- #5424: @josegonzalez Download all src files for go mod dependencies for use in vscode
### Documentation
- #5421: @josegonzalez Document that scaling via app.json will set all other processes to zero
### Tests
- #5422: @josegonzalez Test that build-arg works as expected
### Other
- #5418: @dependabot[bot] chore(deps): bump node from 18-alpine to 19-alpine in /tests/apps/dockerfile-noexpose
- #5417: @dependabot[bot] chore(deps): bump node from 18-alpine to 19-alpine in /tests/apps/dockerfile-procfile-bad
- #5419: @dependabot[bot] chore(deps): bump node from 18-alpine to 19-alpine in /tests/apps/dockerfile-dokku-scale
- #5416: @dependabot[bot] chore(deps): bump node from 18-alpine to 19-alpine in /tests/apps/dockerfile-procfile
- #5415: @dependabot[bot] chore(deps): bump node from 18-alpine to 19-alpine in /tests/apps/dockerfile
- #5413: @dependabot[bot] chore(deps): bump ibiqlik/action-yamllint from 3.1.0 to 3.1.1
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.
Closes#5368
Without this, the LSP within the container continually complains that the source for go files cannot be found. While this method isn't _exactly_ correct, it does help with development.
# History
## 0.28.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.28.3/bootstrap.sh
sudo DOKKU_TAG=v0.28.3 bash bootstrap.sh
```
### New Features
- #5394: @josegonzalez Add support for automatically updating Dockerfile FROM statements via dependabot
### Other
- #5411: @dependabot[bot] chore(deps): bump python from 3.8-buster to 3.10.0-buster in /tests/apps/dockerfile-release
- #5400: @dependabot[bot] chore(deps): bump node from 4-alpine to 18-alpine in /tests/apps/dockerfile-procfile
- #5405: @dependabot[bot] chore(deps): bump node from 4-alpine to 18-alpine in /tests/apps/dockerfile
- #5397: @dependabot[bot] chore(deps): bump ruby from 2.5.1 to 3.1.2 in /tests/apps/dockerfile-entrypoint
- #5401: @dependabot[bot] chore(deps): bump golang from 1.17.1 to 1.19.2 in /tests/apps/go-fail-postdeploy
- #5403: @dependabot[bot] chore(deps): bump golang from 1.17.1 to 1.19.2 in /tests/apps/zombies-dockerfile-tini
- #5407: @dependabot[bot] chore(deps): bump python from 3.10-alpine to 3.10.8-alpine in /docs/_build
- #5404: @dependabot[bot] chore(deps): bump node from 4-alpine to 18-alpine in /tests/apps/dockerfile-dokku-scale
- #5402: @dependabot[bot] chore(deps): bump node from 4-alpine to 18-alpine in /tests/apps/dockerfile-procfile-bad
- #5398: @dependabot[bot] chore(deps): bump golang from 1.17.1 to 1.19.2 in /tests/apps/go-fail-predeploy
- #5396: @dependabot[bot] chore(deps): bump golang from 1.17.1 to 1.19.2 in /tests/apps/gogrpc
- #5399: @dependabot[bot] chore(deps): bump golang from 1.17.1 to 1.19.2 in /tests/apps/zombies-dockerfile-no-tini
- #5395: @dependabot[bot] chore(deps): bump node from 4-alpine to 18-alpine in /tests/apps/dockerfile-noexpose
There are quite a few images that won't build on ARM, so getting these up to date on a more regular basis is important for local development on M1 Macs (selfish, I know).
# History
## 0.28.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.28.2/bootstrap.sh
sudo DOKKU_TAG=v0.28.2 bash bootstrap.sh
```
### Bug Fixes
- #5393: @josegonzalez Correct issue with replacing the version in the installation guide
- #5354: @josegonzalez Report the correct value for the letsencrypt server
- #5347: @josegonzalez Set correct version on builder-lambda plugin
### New Features
- #5392: @josegonzalez Add support for devcontainers on ARM64 instances
### Documentation
- #5365: @josegonzalez Use correct indentation for embedded list in remote commands documentation
- #5357: @josegonzalez Reference blog on main domain
- #5355: @josegonzalez Autogenerate documentation in CI
- #5351: @josegonzalez Fix formatting on list in deployment tasks
- #5328: @holtergram Call out git remote change when renaming an app
- #5344: @josegonzalez Generate docs via mkdocs
- #5342: @josegonzalez Ensure doc links work on github as well as on docs site
- #5336: @josegonzalez Add note about docker-compose requirement for using the caddy plugin
- #5337: @josegonzalez Add note about docker-compose requirement for using the traefik…
- #5332: @cdubz Remove errant semicolon from wget command
- #5329: @josegonzalez Use updated url for gliderlabs slack invite app
- #5315: @alexislefebvre Fix doc link for systems with less than 1GB memory
### Other
- #5382: @dependabot[bot] chore(deps): bump sinatra from 2.2.2 to 3.0.2 in /tests/apps/ruby
- #5386: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 224 to 225 in /tests/apps/php
- #5361: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.11 to 11.0.12 in /tests/apps/java
- #5346: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 223 to 224 in /tests/apps/php
# History
## 0.28.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.28.0/bootstrap.sh
sudo DOKKU_TAG=v0.28.0 bash bootstrap.sh
```
See the [0.28.0 migration guide](/docs/appendices/0.28.0-migration-guide.md) for more information on migrating to 0.28.0.
### Bug Fixes
- #5299: @josegonzalez Do not trigger restarts when mutating config globally
- #5298: @josegonzalez Set core.bare=true on correct repository path
### New Features
- #5300: @josegonzalez Add the ability to disable the init process
- #5295: @josegonzalez Add an official caddy proxy implementation
- #5293: @josegonzalez Add an official traefik proxy implementation
- #5202: @josegonzalez Add builder-lambda plugin
### Documentation
- #5296: @janlavicka Fix typo in kubernetes docs
- #5288: @josegonzalez Do not have bottom border float on page
- #5283: @alexgleason Homepage: fix link in quick install guide
### Other
- #5297: @josegonzalez Update vector image
- #5294: @josegonzalez Document and enable alternative proxy implementations
- #5291: @dependabot[bot] chore(deps): bump werkzeug from 2.2.1 to 2.2.2 in /tests/apps/python-flask
- #5292: @dependabot[bot] chore(deps): bump flask from 2.2.1 to 2.2.2 in /tests/apps/multi
- #5290: @dependabot[bot] chore(deps): bump flask from 2.2.1 to 2.2.2 in /tests/apps/python-flask
- #5227: @josegonzalez Drop forwarded port from vagrant setup
- #5285: @josegonzalez Update all development dependencies
- #5240: @josegonzalez Drop support for CentOS, Fedora, OpenSuse, as well as Debian 9
- #5281: @dependabot[bot] chore(deps): bump flask from 2.1.3 to 2.2.1 in /tests/apps/multi
- #5280: @dependabot[bot] chore(deps): bump flask from 2.1.3 to 2.2.1 in /tests/apps/python-flask
- #5284: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 222 to 223 in /tests/apps/php
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.
This makes it a bit more clear as to where things are being redirected for web containers.
Also gate the https entrypoint behind the letsencrypt integration.
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.
We will no longer support CentOS, Fedora, and Opensuse as installation targets. These are not actively maintained by anyone with commit rights and occasionally cause issues for users as they are not tested during the release process.
Rather than have subpar support for an untested operating system, we're removing support for them completely. Users of these operating systems should take a look migration to the docker-based installation method, which will always be tested and supported by the project.
Additionally, drop support for Debian 9 as it is now EOL.
# History
## 0.27.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.9/bootstrap.sh
sudo DOKKU_TAG=v0.27.9 bash bootstrap.sh
```
### Bug Fixes
- #5273: @josegonzalez Correct issue where more complex docker args were not properly parsed when scheduling containers
- #5272: @josegonzalez Add support for --global as app name when calling config-get trigger
- #5263: @alexgleason Update deprecated apt-key command
### New Features
- #5262: @josegonzalez Run shfmt against all test files
- #5257: @chrisjdixon Move nginx.conf.d includes after all other hard-coded config to allow for overrides
### Other
- #5184: @yasoob New website. Closes#5175
- #5270: @dependabot[bot] chore(deps): bump werkzeug from 2.2.0 to 2.2.1 in /tests/apps/python-flask
- #5265: @dependabot[bot] chore(deps): bump werkzeug from 2.1.2 to 2.2.0 in /tests/apps/python-flask
- #5264: @dependabot[bot] chore(deps): bump sinatra from 2.2.1 to 2.2.2 in /tests/apps/ruby
- #5261: @dependabot[bot] chore(deps): bump luizm/action-sh-checker from 0.4.0 to 0.5.0
- #5258: @dependabot[bot] chore(deps): bump sinatra from 2.2.0 to 2.2.1 in /tests/apps/ruby
In cases where a docker arg uses backticks - which may happen with docker labels - scheduled containers would fail to support these due to performing a double-eval. This is particularly noticeable for traefik labels, where backticks and parenthesis are common. This fix properly handles docker args as an array instead of performing an extra eval when scheduling containers.
The trigger in use _should_ be config-get-global, but some calling code does not check, so adding support here will ensure the calling code gets what it expects.
Refs #5269
# History
## 0.27.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.8/bootstrap.sh
sudo DOKKU_TAG=v0.27.8 bash bootstrap.sh
```
### Bug Fixes
- #5232: @YuukiHogo builder-build fix for DOKKU_DOCKERFILE_CACHE_BUILD and DOKKU_DOCKER_BUILD_OPTS variables
### New Features
- #5255: @josegonzalez export DOKKU_COMMAND for use in authentication systems
### Other
- #5250: @dependabot[bot] chore(deps): bump flask from 2.1.2 to 2.1.3 in /tests/apps/multi
- #5251: @dependabot[bot] chore(deps): bump flask from 2.1.2 to 2.1.3 in /tests/apps/python-flask
- #5245: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 221 to 222 in /tests/apps/php
Some auth systems may decide that an app is not available for use by a particular command vs making them wholly available or not. Exporting the variable here allows such systems to function correctly.
# History
## 0.27.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.7/bootstrap.sh
sudo DOKKU_TAG=v0.27.7 bash bootstrap.sh
```
### Bug Fixes
- #5238: @josegonzalez Respect dokku system user/group when setting storage permissions on installation
### New Features
- #5239: @josegonzalez Add builder-type and image-stage labels to all images
### Documentation
- #5241: @josegonzalez Clarify where logs are pulled from and general log shipping stance
- #5237: @josegonzalez Fix builder-pack:set command example
### Other
- #5235: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 220 to 221 in /tests/apps/php
While it is unfortunate that we don't store logs locally, doing so is actually a fairly difficult ask. Rather than pretending the problem doesn't exist, we'll clarify how logs are currently fetched, as well as point users to integrations/tools that may make their lives easier.
Refs #5234
# History
## 0.27.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.6/bootstrap.sh
sudo DOKKU_TAG=v0.27.6 bash bootstrap.sh
```
### Bug Fixes
- #5225: @josegonzalez Use original app name when setting include_labels for vector source
- #5228: @josegonzalez Always respect app.json formations in scale settings
- #5201: @josegonzalez Use pack as default builder for arm64 servers
### Documentation
- #5230: @josegonzalez Clarify usage of build args to set environment variables for Dockerfile deploys
- #5208: @asokoloski-m Fix typo in dockerfile builder docs
- #5206: @AxelTheGerman Added dokku-litestream to list of community plugins
### Other
- #5218: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 219 to 220 in /tests/apps/php
- #5222: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.10 to 11.0.11 in /tests/apps/java
- #5224: @josegonzalez Document that the community registry plugin should be uninstalled before upgrading past 0.24.x
- #5220: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.9 to 11.0.10 in /tests/apps/java
- #5212: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 218 to 219 in /tests/apps/php
- #5210: @dependabot[bot] chore(deps): bump monolog/monolog from 1.27.0 to 1.27.1 in /tests/apps/php
- #5204: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 217 to 218 in /tests/apps/php
I recently created a plugin for SQLite replication via Litestream to S3. Been using it myself in production for a couple of weeks and was able to successfully restore a backed up DB so I guess it's ready for people to try and be added to this list.
Herokuish is not and will never be supported on arm servers, so attempting to use it will only fail builds.
Also fail when trying to default to herokuish on armhf instances. We can't default to pack as it's just not built for armhf/arm (only arm64).
Closes#5113
# History
## 0.27.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.5/bootstrap.sh
sudo DOKKU_TAG=v0.27.5 bash bootstrap.sh
```
### Bug Fixes
- #5183: @josegonzalez Filter apps when verifying app names
- #5199: @josegonzalez Revert "fix: Vector fails to start container due to --watch-config flag"
- #5197: @holamendi fix: Vector fails to start container due to --watch-config flag
- #5192: @josegonzalez Confirm installation of universe packages when installing on ubuntu
- #5193: @josegonzalez Force-set correct permissions on env files
- #5181: @josegonzalez Ensure we default SSH_NAME to NAME when filtering apps
### New Features
- #5196: @josegonzalez Disable herokuish usage on both armhf and arm64 platforms
- #5194: @josegonzalez Upgrade base Dockerfile image to phusion/baseimage:focal-1.2.0
### Other
- #5200: @dependabot[bot] chore(deps): bump rack from 2.2.3 to 2.2.3.1 in /tests/apps/ruby
- #5198: @dependabot[bot] chore(deps): bump grunt from 1.5.2 to 1.5.3 in /tests/apps/multi
- #5187: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 216 to 217 in /tests/apps/php
This MR splits out the logic such that there is now a binary that handles function based calls without validating the app name. We should only every check the app name for the subcommands and not internally. Internal calls should have their arguments taken at face value.
We will not provide support for herokuish on either as herokuish is meant to be Heroku-compatible, and the Heroku stack does not support arm. Use 'pack' or Dockerfiles for app building instead.
If an env file is written as a root user - for example, during plugin install - the permissions on the file may change to root. This forces those permissions back to what they should be so that the dokku user can edit the files later on.
Closes#5190
Some things must pull *all* apps vs filtered apps (mostly things that write out config files or install triggers). Using an unflitered list is best.
Also, we default to filtering, which should be what most usage needs.
# History
## 0.27.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.2/bootstrap.sh
sudo DOKKU_TAG=v0.27.2 bash bootstrap.sh
```
### Bug Fixes
- #5166: @josegonzalez Ensure permissions for global VHOST file are set to the dokku user on install
- #5141: @josegonzalez fix: set correct version on scheduler plugin
- #5069: @josegonzalez Do not start intermediate container when calling dokku run after a failed build
### New Features
- #5168: @josegonzalez Add support for Ubuntu 22.04
- #5125: @abulava Start the vector logging container after Docker daemon restarts
- #5117: @josegonzalez Upgrade to golang 1.17.9
### Documentation
- #5167: @scottpashley Update client documentation to remove reference to unmaintained python client
### Other
- #5120: @dependabot[bot] chore(deps): bump github/codeql-action from 1 to 2
- #5145: @dependabot[bot] chore(deps): bump jinja2 from 3.1.1 to 3.1.2 in /tests/apps/python-flask
- #5157: @dependabot[bot] chore(deps): bump luizm/action-sh-checker from 0.3.0 to 0.4.0
- #5160: @dependabot[bot] chore(deps): bump docker/setup-buildx-action from 1 to 2
- #5161: @dependabot[bot] chore(deps): bump docker/login-action from 1 to 2
- #5162: @dependabot[bot] chore(deps): bump docker/setup-qemu-action from 1 to 2
- #5153: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/config
- #5152: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express-noappjson
- #5151: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express-noprocfile
- #5150: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express
- #5154: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/gitsubmodules
- #5155: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/.websocket.disabled
- #5163: @dependabot[bot] chore(deps): bump minimist from 1.2.5 to 1.2.6 in /tests/apps/multi
- #5149: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-dokku-scale
- #5148: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-procfile-bad
- #5147: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-procfile
- #5144: @dependabot[bot] chore(deps): bump flask from 2.1.1 to 2.1.2 in /tests/apps/python-flask
- #5143: @dependabot[bot] chore(deps): bump werkzeug from 2.1.1 to 2.1.2 in /tests/apps/python-flask
- #5142: @dependabot[bot] chore(deps): bump flask from 2.1.1 to 2.1.2 in /tests/apps/multi
- #5137: @dependabot[bot] chore(deps): bump grunt from 1.4.1 to 1.5.2 in /tests/apps/multi
- #5119: @dependabot[bot] chore(deps): bump socket.io from 4.4.1 to 4.5.0 in /tests/apps/.websocket.disabled
# History
## 0.27.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.1/bootstrap.sh
sudo DOKKU_TAG=v0.27.1 bash bootstrap.sh
```
### Bug Fixes
- #5095: @josegonzalez Ensure we properly clone and rename common properties
- #5094: @josegonzalez Handle case when apps:clone is run in a directory the dokku user does not have access to
- #5093: @josegonzalez Fix deploy branch setting
- #5068: @josegonzalez Properly set cron-id from flag
### New Features
- #5092: @josegonzalez Warn and exit non-zero when attempting to rebuild from a non-existent branch
- #5103: @naveensrinivasan Included githubactions in the dependabot config
### Documentation
- #5090: @josegonzalez Clarify the exact command that is run once a day by cron tasks
- #5085: @josegonzalez Use issue template form functionality on github
- #5076: @stamp-cmd Lint Markdown, Remove unused links
- #5070: @josegonzalez Add discord as support channel
### Other
- #5107: @dependabot[bot] chore(deps): bump actions/checkout from 2 to 3
- #5105: @dependabot[bot] chore(deps): bump ibiqlik/action-yamllint from 3.0.4 to 3.1
- #5109: @dependabot[bot] chore(deps): bump actions/upload-artifact from 2 to 3
- #5108: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 1.6.0 to 2.1.0
- #5110: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 215 to 216 in /tests/apps/php
- #5104: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 214 to 215 in /tests/apps/php
- #5097: @dependabot[bot] chore(deps): bump werkzeug from 2.1.0 to 2.1.1 in /tests/apps/python-flask
- #5098: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 213 to 214 in /tests/apps/php
- #5096: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.8 to 11.0.9 in /tests/apps/java
- #5091: @josegonzalez Update all dependencies for multi test app
- #5089: @dependabot[bot] chore(deps): bump minimist from 1.2.5 to 1.2.6 in /tests/apps/multi
- #5081: @dependabot[bot] chore(deps): bump jinja2 from 3.0.3 to 3.1.1 in /tests/apps/python-flask
- #5071: @dependabot[bot] chore(deps): bump monolog/monolog from 1.26.1 to 1.27.0 in /tests/apps/php
- #5075: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 212 to 213 in /tests/apps/php
- #5082: @dependabot[bot] chore(deps): bump werkzeug from 2.0.3 to 2.1.0 in /tests/apps/python-flask
- #5086: @dependabot[bot] chore(deps): bump flask from 2.0.3 to 2.1.1 in /tests/apps/multi
- #5087: @dependabot[bot] chore(deps): bump flask from 2.0.3 to 2.1.1 in /tests/apps/python-flask
- #5067: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.2.0 to 3.3.0 in /tests/apps/java
# History
## 0.27.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.0/bootstrap.sh
sudo DOKKU_TAG=v0.27.0 bash bootstrap.sh
```
See the [0.27.0 migration guide](/docs/appendices/0.27.0-migration-guide.md) for more information on migrating to 0.27.0.
### Bug Fixes
- #5063: @josegonzalez Fix buildx support for releases
- #5061: @josegonzalez Use correct token when publish unit test results
- #5057: @josegonzalez Ensure we use the correct variable for WAIT
- #5052: @josegonzalez Run crontab under sudo to support rhel systems
- #5051: @josegonzalez Ensure vector component sources have valid names
- #5035: @nerg4l Fix help flag for logs command
- #5019: @josegonzalez Only rename app domains associated with a global domain
### New Features
- #5064: @josegonzalez Upgrade docker image to ubuntu focal
- #5058: @josegonzalez Add .shellcheckrc
- #5055: @josegonzalez Release dokku for 32-bit Raspbian Bullseye
- #5050: @josegonzalez Set the default memory unit type to megabytes
- #5017: @josegonzalez Add command to clear all proxy configs
### Refactors
- #4921: @josegonzalez Add ability to filter returnable apps
### Documentation
- #5056: @miku86 Fix typo in port management docs
- #5018: @josegonzalez Add warning for setting PORT environment variable
### Other
- #5062: @dependabot[bot] chore(deps): bump django from 3.1.13 to 3.1.14 in /tests/apps/dockerfile-release
- #5053: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 211 to 212 in /tests/apps/php
- #5038: @dependabot[bot] chore(deps): bump flask from 2.0.2 to 2.0.3 in /tests/apps/multi
- #5048: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 210 to 211 in /tests/apps/php
- #5039: @dependabot[bot] chore(deps): bump sinatra from 2.1.0 to 2.2.0 in /tests/apps/ruby
- #5037: @dependabot[bot] chore(deps): bump flask from 2.0.2 to 2.0.3 in /tests/apps/python-flask
- #5036: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 207 to 210 in /tests/apps/php
- #5025: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.7 to 11.0.8 in /tests/apps/java
- #5026: @dependabot[bot] chore(deps): bump werkzeug from 2.0.2 to 2.0.3 in /tests/apps/python-flask
- #5027: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 206 to 207 in /tests/apps/php
- #5021: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 205 to 206 in /tests/apps/php
- #4975: @tcurdt add arm64 to the build
dquote>
dquote> This is a minimal config that can be used in conjunction with text editors to run linting during development. The initial rules are a subset of those we ignore across the codebase. A future update will add further rules as needed and cleanup the codebase.
RHEL blocks users from executing crontab as themselves Because Of Reasons so we need to use sudo instead.
Also refactors file writing to properly support writing the permissions on sudoers files going forward.
Closes#5020
Ideally we could use this to mock out different plugin paths with test implementations of user-auth-app, but for now setting something that won't generally fail is good enough.
This increases the time to list apps from .05s to .2s~.3s on the simplest check, but the increased time is worth it for actually verifyng access to an app (should that need arise).
We'll also want to add the same to app existence checks.
# History
## 0.26.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.8/bootstrap.sh
sudo DOKKU_TAG=v0.26.8 bash bootstrap.sh
```
### Bug Fixes
- #5016: @josegonzalez Properly support the --global flag when detecting the scheduler
- #5015: @josegonzalez Avoid popd errors when dokku is run as root
### New Features
- #5006: @josegonzalez Better go mod support in VSCode Dev Containers
### Documentation
- #5014: @josegonzalez Clarify that all run containers are removed at the end of process execution
- #5010: @josegonzalez Add documentation for ps:restore
- #5009: @josegonzalez Clarify installation documentation
When running the dokku command in a directory that the dokku user does not have access to - such as /root - popd will fail loudly (starting in Ubuntu 16.04). This change ignores those errors and changes the working dir in the bin to /tmp.
Refs #5012
# History
## 0.26.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.7/bootstrap.sh
sudo DOKKU_TAG=v0.26.7 bash bootstrap.sh
```
### Bug Fixes
- #5003: @josegonzalez Respect pre-existing .env files when preparing the herokuish buildenv
- #4950: @emdienn Use exported environment vars during pack build
- #4999: @elhu Purge cache for all apps when calling buildpacks:set-property with --global flag
- #4988: @fomojola Conditionally restart NGINX
- #4922: @josegonzalez Gitignore more built plugin triggers in apps plugin
### New Features
- #4964: @josegonzalez Add log message when running state is false
- #4970: @josegonzalez Log the string error and not bytes when there is an issue updating the cron schedule
- #4924: @josegonzalez Update devcontainer to include aliased go packages
- #4920: @josegonzalez Ensure related go source and vscode plugins are installed in devcontainer
### Documentation
- #4949: @IlyaSemenov docs: update herokuish upgrade instructions
- #4992: @anthonyshew Typo for deploying using image SHA
- #4976: @josegonzalez Update link in header to dokku pro
- #4972: @Dam-Buty Clarify cron:report command
- #4943: @Stormheg Fix typo in registry management documentation
- #4935: @josegonzalez Reword note about env vars in nginx config templates
### Other
- #4995: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 203 to 205 in /tests/apps/php
- #4978: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 201 to 203 in /tests/apps/php
- #4936: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 200 to 201 in /tests/apps/php
- #4937: @dependabot[bot] chore(deps): bump socket.io from 4.3.2 to 4.4.0 in /tests/apps/.websocket.disabled
The command for using an image doesn't include a colon before the `@sha`. Just wanted to help out others because this was tripping me up for like an hour!
Before restarting nginx, check if the current app is using a proxy and if the selected proxy is in fact NGINX. Only then should we bother invoking the nginx reload.
Fixes https://github.com/dokku/dokku/issues/4987
These don't get installed by the go list hack for various reasons. While it would be best to download the _exact_ versions in use, installing the "latest" is better than nothing for local development.
# History
## 0.26.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.6/bootstrap.sh
sudo DOKKU_TAG=v0.26.6 bash bootstrap.sh
```
### Bug Fixes
- #4919: @nerg4l fix: do not validate global flag as an app name
- #4918: @josegonzalez Use netrc binary to properly release dokku client homebrew formula
# History
## 0.26.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.4/bootstrap.sh
sudo DOKKU_TAG=v0.26.4 bash bootstrap.sh
```
### Bug Fixes
- #4899: @josegonzalez Ensure we respect quotes and dollar signs in config vars
- #4890: @josegonzalez Drop which in favor of command -v
### Other
- #4897: @josegonzalez Silence errors when verifying the ssl certificate
- #4891: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 199 to 200 in /tests/apps/php
Due to various changes in how containers are started, these keys were set incorrectly for apps. Since we can use the short-hand --env=ENV format for setting env vars on docker containers, lets do so.
Closes#4895Closes#4896
# History
## 0.26.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.3/bootstrap.sh
sudo DOKKU_TAG=v0.26.3 bash bootstrap.sh
```
### Bug Fixes
- #4889: @josegonzalez Skip herokuish version in report output and disable the herokuish builder on armhf architectures
We don't skip pack as in theory they may be able to support arm in the future. Dockerfile builds should work fine, as long as all images in the FROM directives have arm versions.
Finally, the null builder _should_ always work, but of course YMMV :D
# History
## 0.26.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.2/bootstrap.sh
sudo DOKKU_TAG=v0.26.2 bash bootstrap.sh
```
### Bug Fixes
- #4888: @josegonzalez Ensure installations treat raspbian as similar to debian buster as possible
- #4887: @josegonzalez Ensure we do not add two debian folders in a single armhf package
### New Features
- #4886: @josegonzalez Add created-at time to apps:report output
# History
## 0.26.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.1/bootstrap.sh
sudo DOKKU_TAG=v0.26.1 bash bootstrap.sh
```
### Bug Fixes
- #4884: @josegonzalez Correct recommends entry for bash-completion
### New Features
- #4885: @josegonzalez Add experimental support for arm devices
This specifically targets Raspbian Buster, though releases may work on other debian-based operating systems.
Note that this does _not_ port buildpacks - either herokuish or pack - to Raspbian, and it is likely that users will need to use pack for buildpack support (if/when it is supported on ARM) or Dockerfile for image building.
# History
## 0.26.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.0/bootstrap.sh
sudo DOKKU_TAG=v0.26.0 bash bootstrap.sh
```
See the [0.26.0 migration guide](/docs/appendices/0.26.0-migration-guide.md) for more information on migrating to 0.26.0.
### Bug Fixes
- #4882: @josegonzalez Add missing setup/teardown of builder plugin properties
- #4880: @josegonzalez Ensure the null scheduler reports the app as running when in use
- #4871: @josegonzalez Do not error when default Procfile path does not exist when using a custom procfile-path
- #4861: @josegonzalez Add missing clone/rename code for plugins
### New Features
- #4864: @josegonzalez Switch to unauthenticated tap for formula bumping
- #4860: @josegonzalez Add ability to increase the max parallelism when deploying a given process type
### Documentation
- #4883: @josegonzalez Enable vertical scrolling on the version selector
- #4879: @josegonzalez Clarify that the docker-based dokku installation is ready when a certain message appears
- #4863: @josegonzalez Clarify what is necessary for implementing a scheduler plugin
### Other
- #4874: @josegonzalez Upgrade vector log integration to 0.17.x
- #4881: @josegonzalez Drop bindutils as alternative dependency to bind-utils
- #4869: @dependabot[bot] chore(deps): bump socket.io from 4.2.0 to 4.3.0 in /tests/apps/.websocket.disabled
- #4868: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.6 to 11.0.7 in /tests/apps/java
- #4866: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 198 to 199 in /tests/apps/php
- #4862: @josegonzalez Set deploy-source and metadata at deploy time
- #4853: @josegonzalez Remove dangling images
- #4765: @josegonzalez Allow specifying a single process type to restart
- #4859: @josegonzalez Remove deprecated tar plugin
- #4858: @josegonzalez Remove deprecated tags plugin
- #4857: @josegonzalez Implement scheduler management plugin
We now have too many versions for it to show up on a modern-ish laptop screen, so enabling scrolling will allow folks to choose older versions more easily.
Previously, stderr was ignored when tailing container log output in golang. This change ensures we capture it and also use the correct helper for that output method.
Unfortunately, this breaks CentOS compatibility as they use an older version of yum in CentOS 7. Rather than inconvenience the larger user base, Photon users may wish to provide their own `bind-utils` metapackage that depends on `bindutils`.
Closes#4852
This ensures the value is correct, where previously it was computed based on a file - and therefore did not distinguish between git:from-archive and git:from-image.
Closes#4464
Dokku currently injects an alternate tag into the image. Without this change, deploying new image tags (via push with a Dockerfile or git:from-image) would result in the old images lying around forever. This change ensures they are registered for removal.
Closes#4825
This ensures that unused docker images are _also_ removed. While this will mean a `ps:start` requires a rebuild in the case of a force-stop, it ensures we don't have unused images when destroying apps.
This changes restarts to drop the 'release' part that currently gets triggered, which also helps reduce the possibility that a new image layer will be added due to predeploy deploy triggers.
Note that the old method essentially halfway-rebuilt the app (which was what added the extra layer). This refactor removes that, which is a bc-break.
Additionally, scaling processes will result in deploying _only_ restarting the processes being scaled.
Closes#2184
# History
## 0.25.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.7/bootstrap.sh
sudo DOKKU_TAG=v0.25.7 bash bootstrap.sh
```
### Bug Fixes
- #4855: @josegonzalez Output remote client help when there is no remote host
### New Features
- #4854: @josegonzalez Fix parallel usage for scheduler-docker-local
### Documentation
- #4856: @josegonzalez Add a note to the migration guide regarding using a Procfile for Dockerfile deploys
- #4843: @schmijos Clarify that docker-options are not passed to the launched process but instead to the docker run command
### Other
- #4844: @dependabot[bot] chore(deps): bump werkzeug from 2.0.1 to 2.0.2 in /tests/apps/python-flask
# History
## 0.25.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.6/bootstrap.sh
sudo DOKKU_TAG=v0.25.6 bash bootstrap.sh
```
### Bug Fixes
- #4841: @josegonzalez Ensure pack is run as root user when building apps in docker
- #4836: @josegonzalez Fix custom dockerfile path detection
- #4839: @josegonzalez Choose the correct app when a named remote is specified in the remote ssh client
### New Features
- #4829: @josegonzalez Add ability to schedule process types in parallel
- #4837: @josegonzalez Filter --link and --volume flags during Dockerfile builds
### Documentation
- #4840: @josegonzalez Explain sha256 image digest alternative when reusing docker image tags for git:from-image deployments
### Tests
- #4842: @josegonzalez Set default process list in test cnb buildpacks
### Other
- #4832: @dependabot[bot] chore(deps): bump flask from 2.0.1 to 2.0.2 in /tests/apps/python-flask
- #4833: @dependabot[bot] chore(deps): bump jinja2 from 3.0.1 to 3.0.2 in /tests/apps/python-flask
- #4831: @dependabot[bot] chore(deps): bump flask from 2.0.1 to 2.0.2 in /tests/apps/multi
The link flag was previously not filtered _after_ fetching build args for dockerfile builds, which meant if a plugin exposed that in it's own docker-args-build trigger, it would break deploys.
Additionally, allow for whitespaces between link and volume flags.
# History
## 0.25.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.5/bootstrap.sh
sudo DOKKU_TAG=v0.25.5 bash bootstrap.sh
```
### Bug Fixes
- #4787: @josegonzalez Do not require double quotes when issuing dokku run commands
- #4816: @josegonzalez Set the DOKKU_HOST_ROOT on docker container start
- #4810: @josegonzalez Handle udp ports when fetching network config
- #4812: @josegonzalez Silence stderr when fetching a command from the Procfile
- #4800: @josegonzalez Add help2man os package for copyfiles make target to devcontainer
- #4796: @josegonzalez Remove the --restart flag from pre-deploy chown containers
### New Features
- #4809: @josegonzalez Implement storage:ensure-directory command
- #4801: @josegonzalez Expose git-from-archive and git-from-image plugin triggers
- #4785: @josegonzalez Add support for VSCode Dev Containers
### Documentation
- #4819: @stephenheron Fixed typo in tar documentation
- #4824: @dy3l Fix GitLab case
- #4822: @josegonzalez Add a note about using the registry:login command for private image deployments
- #4808: @francipvb Added a comment about Dockerfile deployment
- #4807: @FinnWoelm Docs: Fix instructions for enabling Docker Buildkit
- #4786: @josegonzalez Add missing argument from trigger documentation
- #4780: @adam12 Update source for `dokku-update`
### Tests
- #4828: @josegonzalez Update golang in test apps to latest version
- #4815: @josegonzalez tests: use python3 shebang for shellcheck-to-junit script
- #4814: @josegonzalez Add wget to devcontainer to fix shfmt installation
- #4791: @josegonzalez Fix test running in devcontainer
### Other
- #4813: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 197 to 198 in /tests/apps/php
- #4802: @dependabot[bot] chore(deps): bump django from 3.1.12 to 3.1.13 in /tests/apps/dockerfile-release
- #4784: @josegonzalez Upgrade vector image to 0.16.x
When deploying, if the procfile-get-command fails for a given process, this causes an error to output to stderr. We instead silence this as the error isn't important.
When an app only has UDP ports exposed, deploys will fail as we expect there to be a single TCP port.
While we _should_ support both, the easier fix is to ignore things and move on. Users can manually expose UDP ports as necessary via the -p flag (or by not specifying the port as a UDP port).
One quirk discovered during tests is that disabling zero-downtime deploys results in odd output, but also a deploy can succeed even if one of the processes that skipped zero-downtime fails. We should fix this in another PR, but this is documented in tests for now.
Closes#4804
# History
## 0.25.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.4/bootstrap.sh
sudo DOKKU_TAG=v0.25.4 bash bootstrap.sh
```
### Bug Fixes
- #4775: @josegonzalez Add support for url-encoded vector-sink config values …
- #4777: @josegonzalez Set correct version for registry plugin
### Documentation
- #4776: @josegonzalez Clarify valid values for container-type when entering containers
### Other
- #4774: @dependabot[bot] chore(deps): bump sqlparse from 0.4.1 to 0.4.2 in /tests/apps/dockerfile-release
Previously, a user could inadvertently override the type or the inputs value by specifying those in their config. Instead, we force-set these so that users do not have potentially invalid config.
# History
## 0.25.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.3/bootstrap.sh
sudo DOKKU_TAG=v0.25.3 bash bootstrap.sh
```
### Bug Fixes
- #4767: @josegonzalez Output logs when container rename fails and continue on
- #4764: @josegonzalez Reference correct plugin when setting up app-json plugin
### Refactors
- #4741: @josegonzalez Use a Dockerfile to speed up env var injection for herokuish app builds
### Documentation
- #4763: @josegonzalez Remove install doc references to removed web installer
### Other
- #4766: @josegonzalez Capitalize certain log messages for aesthetic reasons
This allows folks to later investigate why the rename failed (probably an app bug) and helpfully posts the container logs.
If multiple containers fail, they may have a ton of output, but this is better than not knowing what is going on.
Closes#3900
This makes it easier to track a Dokku container vs an intermediate container or something created external to Dokku.
The container is properly renamed later on, so the `upcoming` part is just an indicator that the container has potentially not yet passed healthchecks.
# History
## 0.25.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.2/bootstrap.sh
sudo DOKKU_TAG=v0.25.2 bash bootstrap.sh
```
### Bug Fixes
- #4760: @josegonzalez Add missing rsync to OS dependency list for git:sync command
### New Features
- #4761: @josegonzalez Correct permissions for userns support
- #4742: @ashkulz bootstrap: add support for Debian 11 (bullseye)
### Documentation
- #4747: @erickedji Fix process management references to formation key in app.json
### Other
- #4753: @dependabot[bot] chore(deps): bump socket.io from 4.1.3 to 4.2.0 in /tests/apps/.websocket.disabled
- #4750: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 196 to 197 in /tests/apps/php
- #4758: @ltalirz Fix typo in network docs
- #4748: @trival Remove spare backtick in 0.25.0-migration-guide.md
Herokuish app builds currently spin up a temporary container and then commit that container. The new approach uses a Dockerfile to perform those same actions, avoiding the need for the temporary container.
# History
## 0.25.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.1/bootstrap.sh
sudo DOKKU_TAG=v0.25.1 bash bootstrap.sh
```
### Bug Fixes
- #4736: @josegonzalez Ensure herokuish deploys respects the env vars during the release process
### Documentation
- #4734: @josegonzalez docs: add github sponsorship link to contributing docs
The dokku_release command adds more "stuff" by virtue of calling builder-release (the herokuish builder injects env vars).
This more closely matches previous order of operations.
Closes#4737
# History
## 0.25.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.0/bootstrap.sh
sudo DOKKU_TAG=v0.25.0 bash bootstrap.sh
```
See the [0.25.0 migration guide](/docs/appendices/0.25.0-migration-guide.md) for more information on migrating to 0.25.0.
### Bug Fixes
- #4733: @josegonzalez Force grep to run in quiet mode in domains:add call
- #4732: @josegonzalez Ensure image cleanup does not impact the stack image and refactor container/image cleanup
- #4731: @josegonzalez Respect debconf selections where possible
- #4729: @josegonzalez Correct count check for user-auth trigger
- #4721: @josegonzalez Recursively sync submodules
- #4717: @josegonzalez Silence stderr when checking for ufw on debian systems
- #4716: @josegonzalez Suppress dos2unix stderr output during Dockerfile builds
- #4686: @josegonzalez Ensure repository is bare when calling git:sync
- #4684: @josegonzalez Install gpg-agent in bootstrap script
- #4683: @josegonzalez Strip published port flags when triggering deploy tasks
- #4651: @josegonzalez Do not attempt to retire when there was no pre-existing container
- #4639: @josegonzalez Correct path for azure-vm releases
### New Features
- #4730: @josegonzalez Execute motd at the end of the install
- #4719: @josegonzalez Add support for routing an app to a specified host:port
- #4715: @josegonzalez Switch from xip.io to sslip.io
- #4460: @josegonzalez Implement registry plugin
- #4711: @josegonzalez Enable installing on RPM systems where bind-utils is bindutils
- #4687: @josegonzalez Output message explaining how to remove a deploy lock when a lock is encountered
- #4682: @josegonzalez Properly space report output
- #4502: @josegonzalez Add monorepo support
- #4509: @josegonzalez Add ability to specify initial network
- #4641: @dbazile Add initial support for installing onto Fedora
### Refactors
- #4508: @josegonzalez Add support for the formation key in app.json
- #4507: @josegonzalez Drop support for Ubuntu 16.04
### Documentation
- #4723: @josegonzalez Clarify buildkit instructions
- #4718: @josegonzalez Update link to azure installation on homepage
- #4714: @josegonzalez Swap from freenode to libera.chat
- #4712: @josegonzalez Clarify the shape of the command that should be entered in app.json for a cron task
- #4709: @josegonzalez Add migration note for deprecation of ubuntu 16.04
- #4697: @josegonzalez Specify that run containers use the same image
- #4688: @josegonzalez Add a note on recovering networks
- #4689: @josegonzalez Add a note about wildcards in the installation doc page
- #4680: @josegonzalez Cleanup markdown lint errors
- #4679: @josegonzalez Cleanup markdown lint errors
- #4678: @josegonzalez Cleanup markdown lint errors
- #4677: @josegonzalez Cleanup markdown lint errors
- #4672: @bjab Fix typo in pack builder docs
- #4668: @RealOrangeOne Make example gitlab-ci script a list
- #4673: @eltociear Fix comment typo in dokku binary
- #4661: @dy3l Fix case style
- #4647: @AngCosmin Fixed unable to find version `v1` for official Github Action
### Tests
- #4693: @josegonzalez Add package.lock for test app
- #4685: @josegonzalez Remove ci skip note in PULL_REQUEST_TEMPLATE.md
- #4681: @josegonzalez Ignore duplication warnings in codacy
- #4644: @josegonzalez Update unit test publisher to latest
### Other
- #4726: @josegonzalez Drop web installer in favor of setup via cli
- #4713: @josegonzalez Make heroku-20/focal the default stack for herokuish builds
- #4707: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 195 to 196 in /tests/apps/php
- #4701: @josegonzalez Revamp dokku run command
- #4671: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 193 to 195 in /tests/apps/php
- #4674: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.5 to 11.0.6 in /tests/apps/java
- #4652: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.4 to 11.0.5 in /tests/apps/java
- #4653: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.1.2 to 3.2.0 in /tests/apps/java
- #4648: @dependabot[bot] chore(deps): bump django from 3.1.9 to 3.1.12 in /tests/apps/dockerfile-release
- #4645: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.3 to 11.0.4 in /tests/apps/java
- #4642: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 192 to 193 in /tests/apps/php
By removing the image cleanup registration, we avoid cases where we delete gliderlabs/herokuish, which may cause issues for users in airgapped installations (where the image may not be pullable from a registry).
This will continue to not override anyone's global domain preferences, but will at least ensure we set the domain prior to the default injected in 00_dokku-standard#install.
Closes#4065
This makes the installation a bit more secure by ensuring a user does not accidentally expose a way for unauthorized users to add new ssh keys to the system.
Additionally, this removes the extra HOSTNAME file to make the initial install process easier (that file was not modifiable by any dokku commands.
Closes#2247
This is useful when there is a service not managed by Dokku but should be exposed via the Dokku routing layer. As an example, some binaries (consul, nomad, vault) expose web uis, and are traditionally run on the host directly vs in a container.
Closes#4665
Freenode is basically offline at this point and we've had a libera.chat for a while, so we should point to that.
Also default all real-time communication to Slack.
Finally, remove prominent links to IRC. While libera is still available, the lack of monitoring makes it not a great way to provide support to users.
These flags are not commonly invoked by users, causing issues when cleaning up old containers. Rather than instruct users to use some random flag, just change the default to what is likely to be more common.
We should treat the project.toml as an optional file, as is the Procfile. Additionally, moving the file into place early will ensure there is no chance of selecting the wrong file.
As of April 2021, it will no longer be an LTS release, and thus us supporting it will increase maintenance burdens.
Also switch CI to use 18.04, so as to test what we currently support.
Closes#4505
# History
## 0.24.10
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.10/bootstrap.sh
sudo DOKKU_TAG=v0.24.10 bash bootstrap.sh
```
### Bug Fixes
- #4638: @josegonzalez Schedule a retire as early as possible
### Documentation
- #4635: @hiepxanh Add buildkit cache example to Dockerfile docs
- #4632: @scflode Fix typo in docs for GitHub Actions
### Other
- #4637: @dependabot[bot] chore(deps): bump django from 3.1.8 to 3.1.9 in /tests/apps/dockerfile-release
Rather than wait for all containers to come up successfully, immediately schedule a retirement of the old container. We'll still perform a disown'd removal after a successful deploy, but we _also_ schedule a retirement when:
- the new container is run successfully, before we update the container id file
- the new container fails and we run the kill_new command (the schedule is there to ensure removal if the container removal commands fail)
Closes#4576
# History
## 0.24.9
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.9/bootstrap.sh
sudo DOKKU_TAG=v0.24.9 bash bootstrap.sh
```
### Bug Fixes
- #4617: @josegonzalez Actually use the null buildpack for the sample python app
- #4616: @josegonzalez Update azure-vm file paths to handled azure renames
### New Features
- #4629: @josegonzalez Upgrade dokku docker image to latest bionic release
### Documentation
- #4622: @allanitis Update nginx logging configuration example to better support AWS Cloudwatch
### Other
- #4627: @Tarow Respect custom stack when using cloud native builder
- #4619: @dependabot[bot] chore(deps): bump flask from 2.0.0 to 2.0.1 in /tests/apps/python-flask
- #4628: @dependabot[bot] chore(deps): bump monolog/monolog from 1.26.0 to 1.26.1 in /tests/apps/php
- #4618: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.2 to 11.0.3 in /tests/apps/java
# History
## 0.24.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.24.8/bootstrap.sh
sudo DOKKU_TAG=v0.24.8 bash bootstrap.sh
```
### Bug Fixes
- #4615: @josegonzalez Remove empty plugin directories during upgrade
- #4613: @josegonzalez Correct failing repo test
- #4612: @josegonzalez fix: always retire deployment task containers
### Documentation
- #4607: @serixscorpio Update link to dokku on Azure deployment page
- #4583: @josegonzalez Set correct redirect for installation
### Other
- #4610: @dependabot[bot] chore(deps): bump jinja2 from 2.11.3 to 3.0.1 in /tests/apps/python-flask
- #4614: @dependabot[bot] chore(deps): bump flask from 2.0.0 to 2.0.1 in /tests/apps/multi
- #4611: @dependabot[bot] chore(deps): bump thin from 1.8.0 to 1.8.1 in /tests/apps/ruby
- #4609: @dependabot[bot] chore(deps): bump socket.io from 4.0.2 to 4.1.2 in /tests/apps/.websocket.disabled
- #4608: @dependabot[bot] chore(deps): bump werkzeug from 1.0.1 to 2.0.1 in /tests/apps/python-flask
- #4600: @dependabot[bot] chore(deps): bump flask from 1.1.2 to 2.0.0 in /tests/apps/multi
- #4598: @dependabot[bot] chore(deps): bump flask from 1.1.2 to 2.0.0 in /tests/apps/python-flask
- #4592: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 191 to 192 in /tests/apps/php
- #4581: @dependabot-preview[bot] Upgrade to GitHub-native Dependabot
Consider [sponsoring Dokku](https://github.com/sponsors/dokku). Sponsorship goes directly to supporting activities such as fixing bugs and general maintenance.
- type:textarea
id:description
attributes:
label:Description of problem
description:What happened? What did you expect to happen?
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce
description:What are the steps that we need to follow to reproduce this issue?
validations:
required:true
- type:textarea
id:report-output
attributes:
label:dokku report $APP_NAME
description:Please paste the output of the command `dokku report $APP_NAME`, where `$APP_NAME` is the name of your app
validations:
required:true
- type:textarea
id:additional-output
attributes:
label:Additional information
description:|
This information is useful for debugging app issues:
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable)
If a deploy is failing or behaving unexpectedly:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- If using buildpacks, which custom buildpacks are in use
- If using a Dockerfile, the contents of that file
- If it exists, the contents of your Procfile.
validations:
required:false
- type:textarea
id:logs
attributes:
label:"Output of failing commands after running: dokku trace:off"
render:shell
validations:
required:false
- type:textarea
id:trace-logs
attributes:
label:"Output of failing commands after running: dokku trace:on"
description:|
**BEWARE**: `dokku trace:on` will cause some commands to print environment variables, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXX
description:Is your deploy failing while building your application using buildpacks? Check this out.
labels:["upstream: buildpacks"]
body:
- type:markdown
attributes:
value:|
If your build is stuck downloading something, compiling a file, or seems to always fail around the same area, Github Issues is not a great place to debug. This is because these sorts of issues tend to take a lot of back and forth to figure out, and the code for buildpacks is not generally maintained by the Dokku project.
<details>
<summary>Debugging tips:</summary>
- If you see text that says `Killed` in your output, attempt to increase free memory by using a larger server or [add swap memory](https://dokku.com/docs/getting-started/troubleshooting/#build-fails-with-killed-message).
- Turn on buildpack trace mode via `dokku config:set $APP_NAME BUILDPACK_XTRACE=1` and retry your deploy. Not all buildpacks support this, but many will output extra debugging information.
- Your hosting provider may have issues accessing AWS S3. Verify a slow/stalled download works by directly curling the file from your host.
- Many buildpacks allow downloading a file from an alternative location specified via environment variable.
- [Increase curl timeouts](https://dokku.com/docs/getting-started/troubleshooting/#deployment-fails-because-of-slow-internet-connection-messages-s) if you see gzip download issues.
- If using multi-buildpack support but a buildpack is failing to apply, ensure you have any files necessary for the `bin/detect` script of the buildpack to `exit 0`. Selected buildpacks must still pass the detection phase in order to be used.
</details>
If you are still having issues, file a ticket here and then further discussing the ticket in one of our [Monitored Support Channels](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations) (Discord, Github Discussions, Slack). Your filed ticket may be closed or locked, but any subsequent discovery will be posted to the ticket for posterity.
- type:textarea
id:description
attributes:
label:Description of problem
description:What happened? What did you expect to happen?
validations:
required:true
- type:textarea
id:report-output
attributes:
label:dokku report $APP_NAME
description:Please paste the output of the command `dokku report $APP_NAME`, where `$APP_NAME` is the name of your app.
validations:
required:true
- type:textarea
id:additional-output
attributes:
label:Additional information
description:|
This information is useful for debugging app issues:
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable)
If a deploy is failing or behaving unexpectedly:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- If using buildpacks, which custom buildpacks are in use
- If it exists, the contents of your Procfile.
validations:
required:true
- type:textarea
id:logs
attributes:
label:"Output of failing deploy after running: dokku trace:off"
render:shell
validations:
required:true
- type:textarea
id:trace-logs
attributes:
label:"Output of failing deploy after running: dokku trace:on"
description:|
**BEWARE**: `dokku trace:on` will cause some commands to print environment variables, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXX
description:Have an idea for a new feature? Ask away!
labels:["needs: plan","type: enhancement"]
body:
- type:markdown
attributes:
value:|
While pull requests are always welcome, feel free to fill this out with an idea of what you would like to happen and we can discuss if and how it should be implemented in Dokku.
Consider [sponsoring Dokku](https://github.com/sponsors/dokku). Sponsorship goes directly to supporting activities such as implementing new features and upgrading existing functionality.
- type:textarea
id:description
attributes:
label:Description of feature
description:When you perform what command or action, what do you think should happen?
The Dokku project would love to welcome your contributions. There are
several ways to help out:
* Create an [issue](https://github.com/dokku/dokku/issues) on GitHub, if you
have found a bug
* Write [test cases](https://dokku.com/docs/development/testing/) for open bug issues
*Write patches for open bug/feature issues, preferably with test cases
included
*Contribute to the [documentation](https://dokku.com/docs/)
*Come up with new ways, non-commercial to show off our [lovely logo](https://avatars1.githubusercontent.com/u/13455795)
* Blog about different ways you are using dokku
* Sponsor the Dokku project financially on [OpenCollective](https://opencollective.com/dokku#support) or [Patreon](https://www.patreon.com/dokku)
- Create an [issue](https://github.com/dokku/dokku/issues) on GitHub, if you have found a bug
- Write [test cases](https://dokku.com/docs/development/testing/) for open bug issues
- Write patches for open bug/feature issues, preferably with test cases included
-Contribute to the [documentation](https://dokku.com/docs/)
- Come up with new ways, non-commercial to show off our [lovely logo](https://avatars1.githubusercontent.com/u/13455795)
-Blog about different ways you are using dokku
-Sponsor the Dokku project financially on [Github](https://github.com/sponsors/dokku), [OpenCollective](https://opencollective.com/dokku#support) or [Patreon](https://www.patreon.com/dokku)
There are a few guidelines that we need contributors to follow so that we have
> If you'd like to sponsor specific functionality, see the project's [Sponsoring](https://github.com/dokku/.github/blob/master/SPONSORING.md) document.
>
> If you need help figuring out how to use a specific buildpack, are seeing an issue in during the buildpack process, or are having issues using multiple buildpacks, please see our [slack channels or github discussion board](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations). Issues pertaining to buildpacks may be closed and locked.
> If you need help figuring out how to use a specific buildpack, are seeing an issue in during the buildpack process, or are having issues using multiple buildpacks, please see our [chat channels or github discussion board](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations). Issues pertaining to buildpacks may be closed and locked.
>
> If you need support for a version of Dokku that is more than a year old, your issue may be closed without an answer. Please upgrade to a recent version.
@@ -31,7 +31,7 @@
> For problems affecting all applications, the report output for a broken application is useful for our debugging.
> In these cases, you may run `dokku report` without any arguments to display the top-level reporting information.
### How (deb/make/rpm) and where (AWS, VirtualBox, physical, etc.) was Dokku installed?:
### How (deb/make) and where (AWS, VirtualBox, physical, etc.) was Dokku installed?
You can then proceed to the ip address or domain name associated with your server to complete the web-based installation.
You can then proceed to configure your server domain (via `dokku domains:set-global`) and user access (via `dokku ssh-keys:add`) to complete the installation.
If you wish for a more unattended installation method, see [these](https://dokku.com/docs/getting-started/install/debian/#unattended-installation) docs.
@@ -113,15 +100,15 @@ If you wish for a more unattended installation method, see [these](https://dokku
## Documentation
Full documentation - including advanced installation docs - are available online at [https://dokku.com/docs/getting-started/installation/](https://dokku.com/docs/getting-started/installation/).
Full documentation - including advanced installation docs - are available online at <https://dokku.com/docs/getting-started/installation/>.
## Support
You can use [Github Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](https://dokku.com/docs/getting-started/troubleshooting/) in the documentation, or join us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku).
You can use [GitHub Issues](https://github.com/dokku/dokku/issues), check [Troubleshooting](https://dokku.com/docs/getting-started/troubleshooting/) in the documentation, or join us on [Gliderlabs Slack in the #dokku channel](https://slack.dokku.com/).
## Contribution
After checking [Github Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](https://dokku.com/docs/getting-started/troubleshooting/) or having a chat with us on [freenode in #dokku](https://webchat.freenode.net/?channels=%23dokku), feel free to fork and create a Pull Request.
After checking [GitHub Issues](https://github.com/dokku/dokku/issues), the [Troubleshooting Guide](https://dokku.com/docs/getting-started/troubleshooting/) or having a chat with us on [Gliderlabs Slack in the #dokku channel](https://slack.dokku.com/), feel free to fork and create a Pull Request.
While we may not merge your PR as is, they serve to start conversations and improve the general Dokku experience for all users.
<strong>Warning:</strong> The SSH key filled out here can grant root access to the server. Please complete the setup as soon as possible.
</div>
<div class="row">
<div class="col">
<h3>Admin Access</h3>
<div class="form-group">
<label for="key">Public SSH Keys</label><br />
<textarea class="form-control" name="keys" rows="5" id="key" placeholder="Begins with 'ssh-rsa', 'ssh-dss', 'ssh-ed25519', 'ecdsa-sha2-nistp256', 'ecdsa-sha2-nistp384', or 'ecdsa-sha2-nistp521'">{ADMIN_KEYS}</textarea>
<small class="form-text text-muted">Public keys allow users to ssh onto the server as the <code>dokku</code> user, as well as remotely execute Dokku commands. They are currently auto-populated from: <code>{AUTHORIZED_KEYS_LOCATION}</code>, and can be changed later via the <a href="https://dokku.com/docs/deployment/user-management/" target="_blank"><code>dokku ssh-keys</code></a> plugin.</small>
</div>
</div>
</div>
<div class="row">
<div class="col">
<h3>Hostname Configuration</h3>
<div class="form-group">
<label for="hostname">Hostname</label>
<input class="form-control" type="text" id="hostname" name="hostname" value="{HOSTNAME}" placeholder="A hostname or ip address such as {HOSTNAME}" />
<small class="form-text text-muted">This will be used as the default host for all applications, and can be changed later via the <a href="https://dokku.com/docs/configuration/domains/" target="_blank"><code>dokku domains:set-global</code></a> command.</small>
<label class="form-check-label" for="vhost">Use virtualhost naming for apps</label>
<small class="form-text text-muted">When enabled, Nginx will be run on port 80 and proxy requests to apps based on hostname.</small>
<small class="form-text text-muted">When disabled, a specific port will be setup for each application on first deploy, and requests to that port will be proxied to the relevant app.</small>
</div>
<div class="alert alert-warning small mt-3 d-{UFW_DISPLAY}" role="alert">
<strong>Warning:</strong> UFW is active. To allow traffic to specific ports, run <code>sudo ufw allow PORT</code> for the port in question.
@@ -32,7 +32,7 @@ To extract the backup onto another server, copy the backup to the server and ext
sudo tar -xzvf path/to/dokku/backup.tar.gz -C /
```
At this point, all datastores should be individually started and checked for data integrity. Once this is complete, individual applications can be rebuilt. Please consult the [process management documentation](/docs/processes/process-management.md#rebuilding-apps) for more information on how to rebuild applications.
At this point, all datastores should be individually started and checked for data integrity. Once this is complete, individual apps can be rebuilt. Please consult the [process management documentation](/docs/processes/process-management.md#rebuilding-apps) for more information on how to rebuild apps.
Docker networks generated by Dokku should be recreated. Running `dokku network:report` will output all networks in use by various apps, which can then be used to recreate them via `dokku network:create $NETWORK`.
Networks created by tools other than Dokku may be created as they initially were.
### Docker Image and Tar-based Apps
These applications may fail to rebuild via the normal `ps:rebuild` method. Redeploy these apps by running the original commands used to deploy them
These apps may fail to rebuild via the normal `ps:rebuild` method. Redeploy these apps by running the original commands used to deploy them
### Datastores
@@ -81,14 +87,13 @@ The plugin directory is contained at the `/var/lib/dokku/plugins` directory. Cor
Note that restoring a plugin will not trigger any `install` or `dependencies` triggers. You will need to run these manually. See the [plugin management documentation](/docs/advanced-usage/plugin-management.md#installing-a-plugin) for more information on how to trigger these two hooks.
### Volumes and Static Assets
Dokku doesn't enforce a [300mb](https://devcenter.heroku.com/articles/slug-compiler#slug-size) limit on apps, but it's best practice to keep binary assets outside of git. Since containers are considered volatile in Dokku, external stores like s3 or storage mounts should be used for non-volatile items like user uploads. The Dokku storage core plugin can be used to mount local directories / volumes inside the docker container.
System administrators are highly encouraged to store persistent data in app-specific subdirectories of the path `/var/lib/dokku/data/storage`. This will help ensure restores of the aforementioned primary Dokku directories will restore service to all apps.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your application.
See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your app.
Sometimes you need to run a command on deployment time, but before an app is completely deployed. Common use cases include:
* Checking a database is initialized
* Running database migrations
* Any commands required to set up the server (e.g. something like a Django `collectstatic`)
- Checking a database is initialized
- Running database migrations
- Any commands required to set up the server (e.g. something like a Django `collectstatic`)
To support this, Dokku provides support for a special `release` command within your app's `Procfile`, as well as a special `scripts.dokku` key inside of your app's `app.json` file. Be aware that all commands are run within the context of the built docker image - no commands affect the host unless there are volume mounts attached to your app.
@@ -49,13 +53,89 @@ Please keep the above in mind when utilizing deployment tasks.
> To execute commands on the host during a release phase, see the [plugin creation documentation](/docs/development/plugin-creation.md) docs for more information on building your own custom plugin.
## `app.json` deployment tasks
### Changing the `app.json` location
When deploying a monorepo, it may be desirable to specify the specific path of the `app.json` file to use for a given app. This can be done via the `app-json:set` command. If a value is specified and that file does not exist within the repository, Dokku will continue the build process as if the repository has no `app.json` file.
The default value may be set by passing an empty value for the option:
```shell
dokku app-json:set node-js-app appjson-path
```
The `appjson-path` property can also be set globally. The global default is `app.json`, and the global value is used when no app-specific value is set.
Dokku provides limited support for the `app.json` manifest from Heroku (documentation available [here](https://devcenter.heroku.com/articles/app-json-schema)). The keys available for use with Deployment Tasks are:
-`scripts.dokku.predeploy`: This is run _after_ an app's docker image is built, but _before_ any containers are scheduled. Changes made to your image are committed at this phase.
-`scripts.dokku.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are *not* committed at this phase.
-`scripts.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are *not* committed at this phase.
-`scripts.dokku.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are _not_ committed at this phase.
-`scripts.postdeploy`: This is run _after_ an app's containers are scheduled. Changes made to your image are _not_ committed at this phase.
For buildpack-based deployments, the location of the `app.json` file should be at the root of your repository. Dockerfile-based app deploys should have the `app.json` in the configured `WORKDIR` directory; otherwise Dokku defaults to the buildpack app behavior of looking in `/app`.
@@ -75,7 +155,7 @@ The following is an example `app.json` file. Please note that only the `scripts.
}
```
## Procfile Release command
#### Procfile Release command
> New as of 0.14.0
@@ -87,6 +167,6 @@ To use the `release` command, simply add a `release` stanza to your Procfile.
Pass [options](https://docs.docker.com/engine/reference/run/) to Docker during Dokku's `build`, `deploy` and `run` phases
Pass [container options](https://docs.docker.com/engine/reference/run/) to the `docker run` command during Dokku's `build`, `deploy` and `run` phases
```
docker-options:add <app> <phase(s)> OPTION # Add Docker option to app for phase (comma-separated phase list)
@@ -29,6 +29,8 @@ Manipulation of docker options will not restart running containers. This enables
More information on supported Docker options can be found here: https://docs.docker.com/engine/reference/commandline/run/.
Container options configured via the `docker-options` plugin are not used to modify the process a container runs. Container options are the `[OPTIONS]` portion of the following, where `[CONTAINER_COMMAND]` and `[ARG]` are the process and the arguments passed to it that are launched in the created container: `docker run [OPTIONS] [CONTAINER_COMMAND] [ARG...]`. Please see the documentation for [customizing the run command](/docs/deployment/builders/dockerfiles.md#customizing-the-run-command) or use a [Procfile](/docs/deployment/builders/dockerfiles.md#procfiles-and-multiple-processes) to modify the command used by a Dockerfile-based container.
The preferred method to mount external containers to a Dokku managed container, is to use the Dokku storage plugin.
```
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
storage:ensure-directory [--chown option] <directory> # Creates a persistent storage directory in the recommended storage path
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
```
> The storage plugin is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy/run phase.
@@ -21,50 +21,77 @@ The storage plugin supports the following mount points:
## Usage
This example demonstrates how to mount the recommended directory to `/storage` inside an application called `node-js-app`. For simplicity, the Dokku project recommends using the directory `/var/lib/dokku/data/storage` directory as the root host path for mounts. This directory is created on Dokku installation.
### Creating storage directories
> New as of 0.25.5
A storage directory can be created with the `storage:ensure-directory` command. This command will create a subdirectory in the recommended `/var/lib/dokku/data/storage` path - created during Dokku installation - and prepare it for use with an app.
```shell
# we use a subdirectory inside of the host directory to scope it to just the app
Dokku will then mount the shared contents of `/var/lib/dokku/data/storage/node-js-app` to `/storage` inside the container. Mounts are only available for containers crated via `run` and by the deploy process, and not during the build process. In addition, the host path is never auto-created by either Dokku or Docker, and should be an explicit path, not one relative to the current working directory.
> If the `/storage` path within the container had pre-existing content, the container files will be overrwritten. This may be an issue for users that create assets at build time but then mount a directory at the same place during runtime. Files are not merged.
By default, permissions are set for usage with Herokuish buildpacks. These permissions can be changed via the `--chown` option according to the following table:
Once you have mounted persistent storage, you will also need to restart the application. See the
[process scaling documentation](/docs/processes/process-management.md) for more information.
-`--chown herokuish` (default): Use `32767:32767` as the folder permissions.
- This is used for apps deployed with Buildpacks via Herokuish.
-`--chown heroku`: Use `1000:1000` as the folder permissions.
- This is used for apps deployed with Cloud Native Buildpacks using the `heroku/buildpacks` builder.
-`--chown packeto`: Use `2000:2000` as the folder permissions.
- This is used for apps deployed with Cloud Native Buildpacks using the `cloudfoundry/cnb` or `packeto` builders.
-`--chown false`: Skips the `chown` call.
Users deploying via Dockerfile will want to specify `--chown false` and manually `chown` the created directory if the user and/or group id of the runnning process in the deployed container do not correspond to any of the above options.
> Warning: Failing to set the correct directory ownership may result in issues in persisting files written to the mounted storage directory.
### Mounting storage into apps
Dokku supports mounting both explicit host paths as well as docker volumes via the `storage:mount` command. This takes two arguments, an app name and a `host-path:container-path` or `docker-volume:container-path` combination.
```shell
# mount the directory into your container's /app/storage directory, relative to the container root (/)
# explicit host paths _must_ exist prior to usage.
In the first example, Dokku will then mount the shared contents of `/var/lib/dokku/data/storage/node-js-app` to `/app/storage` inside the container. The mount point is *not* relative to your app's working directory, and is instead relative to the root (`/`) of the container. Mounts are only available for containers created via `run` and by the deploy process, and not during the build process. In addition, the host path is never auto-created by either Dokku or Docker, and should be an explicit path, not one relative to the current working directory.
> If the `/storage` path within the container had pre-existing content, the container files will be over-written. This may be an issue for users that create assets at build time but then mount a directory at the same place during runtime. Files are not merged.
Once persistent storage is mounted, the app requires a restart. See the [process scaling documentation](/docs/processes/process-management.md) for more information.
```shell
dokku ps:restart app-name
```
A more complete workflow may require making a custom directory for your application and mounting it within your `/app/storage` directory instead. The mount point is *not* relative to your application's working directory, and is instead relative to the root (`/`) of the container.
### Unmounting storage
If an app no longer requires a mounted volume or directory, the `storage:unmount` command can be called. This takes the same arguments as the `storage:mount` command, an app name and a `host-path:container-path` or `docker-volume:container-path` combination.
```shell
# creating storage for the app 'node-js-app'
mkdir -p /var/lib/dokku/data/storage/node-js-app
# unmount the directory from your container's /app/storage directory, relative to the container root (/)
You can mount one or more directories as desired by following the above pattern.
Once persistent storage is unmounted, the app requires a restart. See the [process scaling documentation](/docs/processes/process-management.md) for more information.
### Directory Permissions
The host directory should always be owned by the container user and group id. If this is not the case, files may not persist when written to mounted storage.
- Buildpacks via Herokuish: Use `32767:32767` as the file permissions
- For Cloud Native Buildpacks: This will depend on the builder in question, but can be retrieved via the `CNB_USER_ID` and `CNB_GROUP_ID` environment variables on the builder image. Common builders are as follows:
- heroku/buildpacks: `1000:1000`
- cloudfoundry/cnb: `2000:2000`
- packeto: `2000:2000`
- Dockerfile and Docker Image: Use the user and group id which corresponds to the one running the process within the container.
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web applications, like user uploads or large binary assets like images, a directory outside the container should be mounted.
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web apps, like user uploads or large binary assets like images, a directory outside the container should be mounted.
You cannot use mounted volumes during the build phase of a Dockerfile deploy. This is because Docker does not support volumes when executing `docker build`.
> Note: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
> Warning: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
## Application User and Persistent Storage file ownership (buildpack apps only)
## App User and Persistent Storage file ownership (buildpack apps only)
> New as of 0.7.1
By default, Dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
By default, Dokku will execute your buildpack app processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
> NOTE: this user must exist in your herokuish image.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/advanced-usage/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
Additionally, the default `docker-local` scheduler that comes with Dokku will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. See the [docker-local scheduler documentation](/docs/deployment/schedulers/docker-local.md#disabling-chown-of-persistent-storage) docs for more information.
registry:login [--password-stdin] <server> <username> [<password>] # Login to a docker registry
registry:report [<app>] [<flag>] # Displays a registry report for one or more apps
registry:set <app> <key> (<value>) # Set or clear a registry property for an app
```
The registry plugin enables interacting with remote registries, which is useful when either deploying images via `git:from-image` or when interacting with custom schedulers to deploy built image artifacts.
## Usage
### Logging into a registry
The `registry:login` command can be used to log into a docker registry. The following are examples for logging into various common registries:
```shell
# hub.docker.com
dokku registry:login docker.io $USERNAME$PASSWORD
# digitalocean
# the username and password are both defined as the same api token
For security reasons, the password may also be specified as stdin by specifying the `--password-stdin` flag. This is supported regardless of the registry being logged into.
For certain Docker registries - such as Amazon ECR or Google's GCR registries - users may instead wish to use a docker credential helper to automatically authenticate against a server; please see the documentation regarding the credential helper in question for further setup instructions.
### Setting a remote server
To specify a remote server registry for pushes, set the `server` property via the `registry:set` command. The default value for this property is empty string. Setting the value to `docker.io` or `hub.docker.com` will result in the computed value being empty string (as that is the default, implicit registry), while any non-zero length value will have a `/` appended to it if there is not one already.
```shell
dokku registry:set node-js-app server docker.io
```
This property can be set for a single app or globally via the `--global` flag. When set globally, the app-specific value will always overide the global value. The default global value for this property is empty string.
```shell
dokku registry:set --global server docker.io
```
Setting the property value to an empty string will reset the value to the system default. Resetting the value can be done per app or globally.
```shell
# per-app
dokku registry:set node-js-app server
# globally
dokku registry:set --global server
```
The following are the values that should be used for common remote servers:
- notes: The `$AWS_ACCOUNT_ID` and `$AWS_REGION` should match the values for your account and region, respectively. Additionally, an IAM profile that allows `push` access to the repository specified by `image-repo` should be attached to your Dokku server.
- Azure Container Registry:
- value `$REGISTRY_NAME.azurecr.io/`
- notes: The `$AKS_REGISTRY_NAME` should match the name of the registry created on your account.
- Docker Hub:
- value: `docker.io/`
- notes: Requires owning the namespace used in the `image-repo` value.
- Digitalocean:
- value: `registry.digitalocean.com/`
- notes: Requires setting the correct `image-repo` value for your registry.
- Github Container Registry:
- value: `ghcr.io/`
- notes: Requires that the authenticated user has access to the namespace used in the `image-repo` value.
- Quay.io:
- value: `quay.io/`
### Specifying an image repository name
By default, Dokku uses the value `dokku/$APP_NAME` as the image repository that is pushed and deployed. For certain registries, the `dokku` namespace may not be available to your user. In these cases, the value can be set by changing the value of the `image-repo` property via the `registry:set` command.
Setting the property value to an empty string will reset the value to the system default. Resetting the value has to be done per-app.
```shell
# per-app
dokku registry:set node-js-app push-on-release
```
### Pushing images on build
To push the image on release, set the `push-on-release` property to `true` via the `registry:set` command. The default value for this property is `false`. Setting the property to `true` will result in the image being tagged with an ID that is incremented with every release. This tag will be what is used for running app code.
This property can be set for a single app or globally via the `--global` flag. When set globally, the app-specific value will always overide the global value. The default global value for this property is `false`.
```shell
dokku registry:set --global push-on-release true
```
Setting the property value to an empty string will reset the value to the system default. Resetting the value can be done per app or globally.
See the [Supported Resource Management Properties](/docs/advanced-usage/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
See the [Supported Resource Management Properties](/docs/deployment/schedulers/docker-local.md#supported-resource-management-properties) section of the docker local scheduler documentation for more information on how each resource limit maps to Docker.
Resource limits and reservations are applied only during the `run` and `deploy` phases of an application, and will not impact the `build` phase of an application.
This may also be combined with the `--process-type` flag to see app limits on a process-type level. Note that the displayed values are not merged with the defaults.
```shell
dokku resource:limit --process-type web node-js-app
These scheduler implementations may not be complete, though provide enough functionality for a user to get an app deployed via the underlying scheduler.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
scheduler-docker-local:report [<app>] [<flag>] # Displays a scheduler-docker-local report for one or more apps
scheduler-docker-local:set <app> <key> (<value>) # Set or clear a scheduler-docker-local property for an app
```
> New as of 0.12.0
Dokku natively includes functionality to manage application lifecycles for a single server using the `scheduler-docker-local` plugin. It is the default scheduler, but as with all schedulers, it is set on a per-application basis. The scheduler can currently be overridden by running the following command:
As it is the default, unsetting the `DOCKER_SCHEDULER` config variable is also a valid way to reset the scheduler.
```shell
dokku config:unset node-js-app DOCKER_SCHEDULER
```
## Usage
### Disabling chown of persistent storage
The `scheduler-docker-local` plugin will ensure your storage mounts are owned by either `herokuishuser` or the overridden value you have set in `DOKKU_APP_USER`. You may disable this by running the following `scheduler-docker-local:set` command for your application:
This plugin implements various functionality through `plugn` triggers to integrate with Docker for running apps on a single server. The following functionality is supported by the `scheduler-docker-local` plugin.
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-app-rename-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-app-status`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-is-deployed`
-`scheduler-logs`
-`scheduler-logs-failed`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
-`scheduler-tags-create`
-`scheduler-tags-destroy`
## Supported Resource Management Properties
The `docker-local` scheduler supports a minimal list of resource _limits_ and _reservations_. The following properties are supported:
### Resource Limits
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
- See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
### Resource Reservations
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
By default, Dokku will ship a PCI Compliant nginx configuration. For developers whose users are on older browsers or mobile devices, you may need to ship a custom `nginx.conf.sigil` to enable ciphers for older browsers.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
See the [nginx customization](/docs/networking/proxies/nginx/#customizing-the-nginx-configuration) docs for more details.
## Nginx Error Pages
We now ship with nicer error pages by default. You are free to customize your Dokku installation via a custom `nginx.conf.sigil` to change what error pages are displayed in different circumstances.
See the [nginx customization](/docs/configuration/nginx/#customizing-the-nginx-configuration) docs for more details.
See the [nginx customization](/docs/networking/proxies/nginx/#customizing-the-nginx-configuration) docs for more details.
The [dokku-registry](https://github.com/dokku/dokku-registry) plugin is now built-in. This comes with a few changes:
- Builder plugins should call `post-release-builder` at the end of the build.
- The `push` and `pull` command are not implemented. Users wishing to deploy a remote image should use `git:from-image`. Image pushing is not available at this time.
- At this time, remote docker repositories are not automatically created for AWS, and users must create those repositories for their applications as necessary. This may be implemented in the future.
- Docker images are only pushed when configured to do so. See the [registry management documentation](/docs/advanced-usage/registry-management.md) for more details.
Before upgrading, uninstall the registry plugin via `dokku plugin:uninstall registry`. Not doing so will cause issues with Dokku.
## Other
### Changes
- The network plugin can now set an `initial-network` for all containers on creation. This is a replacement for specifying the `--network` flag via the `docker-options` plugin. Please see the [network documentation](/docs/networking/network.md#attaching-an-app-to-a-network) for more information.
- The `dokku run` command now always removes the ephemeral container on exit. Users that need a persistent container should instead specify a `console` process type in their `Procfile` specifying an available shell (usually either `bash` or `sh`) and scale that container appropriately.
- The `pre-deploy` plugin trigger is now called internally by Dokku. Scheduler plugins should avoid calling this trigger, as any image changes introduced by subsequent trigger calls will be ignored.
- The default image used for Herokuish Buildpack builds is now `gliderlabs/herokuish:latest-20`, and is based on both the `heroku-20` stack as well as Ubuntu 20.04. Users that wish to stick with the old, `heroku-18`/Ubuntu 18.04 builder may specify `gliderlabs/herokuish:latest-18` as their builder image. Please see the [herokuish buildpack deployment documentation](/docs/deployment/builders/herokuish-buildpacks.md#customizing-the-buildpack-stack-builder) for more information on how to specify a custom buildpack stack builder.
- This change does not impact any users of Cloud Native Buildpacks.
- We fixed an issue that required extracting Procfiles at the beginning of a deploy. Due to this change, a `Dockerfile` app contains a `Procfile` that does not specify a `web` process will fail to start. Usage of a `Procfile` with _only_ a `release` command should be replaced with a `scripts.dokku.postdeploy` deployment task in the `app.json` file. The alternative is to define the `web` process in the `Procfile`. See the [deployment task documentation](/docs/advanced-usage/deployment-tasks.md) for more information.
### Deprecations
- In previous versions of Dokku, the only way to specify a custom `Dockerfile` was to use the `docker-options` plugin to set the `--file` flag for a docker build. As of 0.25.0, the `builder-dockerfile:set` command should be used instead, as outlined in the [docs here](/docs/deployment/builders/dockerfiles.md#changingthe-dockerfile-location). Usage of the old method should be migrated to the new method.
- The `--rm` and `--rm-container` flags may be specified but no longer have any effect on `dokku run`.
- The `--detach` flag is deprecated in favor of the `run:detached` command.
- The `DOKKU_SCALE` file is deprecated. Please see the [process management documentation](/docs/processes/process-management.md#manually-managing-process-scaling) for more information on it's replacement with the `formation` key of the `app.json` file.
- The hooks `post-release-buildpack`, `post-release-dockerfile`, and `post-release-pack` are deprecated in favor of `post-release-builder`. See the [plugin triggers documentation](https://dokku.com/docs/development/plugin-triggers/#post-release-builder) for more details.
## Removals
- As of April 2021, Ubuntu 16.04 is no longer an LTS release, and support has been removed. Packages may still install on older versions of Ubuntu, but are no longer tested, and therefore no support will be provided.
- The web installer has been removed. Users are now required to setup Dokku via cli commands. This change was made to combat potential security issues where users ignored the web installer, allowing unauthorized users to add their keys to the host.
- The `scheduler-docker-cleanup` plugin trigger has been removed from the scheduler interface, and is no longer invoked.
- The `tags` plugin - deprecated in [0.24.0](/docs/appendices/0.24.0-migration-guide.md) - was removed. Users are highly encouraged to switch their workflows to `git:from-image`.
- The `tar` plugin - deprecated in [0.24.0](/docs/appendices/0.24.0-migration-guide.md) - was removed. Users are highly encouraged to switch their workflows to `git:from-archive`.
## Changes
- The `scheduler` plugin now controls the scheduler in use for deploys. Apps will have their `DOKKU_SCHEDULER` environment variables migrated to the scheduler plugin, after which that value will be removed from said app. Please see the [scheduler documentation](/docs/deployment/schedulers/scheduler-management.md) for more information.
- The `deploy-source` metadata from `apps:report` is now no longer computed on the fly, but hydrated at deploy time via the `deploy-source-set` trigger. This value may be empty until your next deploy.
- Additionally, the `deploy-source` trigger has now been removed.
Support for the following operating systems has been removed:
- CentOS 7
- Debian 9 (Stretch)
- Fedora
- OpenSuse
Dokku will no longer provide packages for RPM based systems. Debian 9 users _may_ use new Debian packages, though support is not guaranteed.
All users are encouraged to install Dokku via the [Docker-based installation method](/docs/getting-started/install/docker.md), or switch to a supported operating system.
## Deprecations
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 instllation method to the [Docker-based installation method](/docs/getting-started/install/docker.md) to avoid any disruption in usage.
## Additions
New in 0.28.0 are the Caddy and Traefik plugins. As community plugins wrapping these proxies exist, users should:
- Recommended: Uninstall the community plugin in question and switch all config to the new plugins.
- Upgrade the community plugin to a version that does not use the `proxy:set` value of `caddy` or `traefik`.
- The output of `run:detached` now uses the container name - eg. `node-js-app.run.1` - vs the container id.
- The ID of `cron` tasks is now base36-encoded instead of base64-encoded.
- The `nginx.conf.sigil` is now extracted when source code is extracted for a build and not from the built image. Users can specify alternative paths via the `nginx-conf-sigil-path` property of the `nginx` plugin. See the [nginx documentation](/docs/networking/proxies/nginx.md#customizing-the-nginx-configuration) for more information on how to configure the `nginx.conf.sigil` path for your application.
- For deploys via `git:from-image`, the `nginx.conf.sigil` file will be extracted from the source image, respecting the value of `nginx-conf-sigil-path`.
- The `Procfile` is now extracted when source code is extracted for a build and not from the built image. Users can specify alternative paths via the `procfile-path` property of the `ps` plugin. See the [process management documentation](/docs/processes/process-management.md#changing-the-procfile-location) for more information on how to configure the `Procfile` path for your application.
- For deploys via `git:from-image`, the `Procfile` file will be extracted from the source image, respecting the value of `procfile-path`.
- The existing `pre-restore` hook has been renamed to `scheduler-pre-restore`. There is a new `pre-restore` hook that is triggered within the `ps:restore` command prior to restoring any apps.
- Nginx init commands are now performed via systemctl on Ubuntu systems when `/usr/bin/systemctl` is available.
## Removals
- The `DOKKU_WAIT_TO_RETIRE` environment variable has been migrated to a `checks` property named `wait-to-retire` and will be ignored if set as an environment variable.
- The `domains-setup` trigger has been removed. Initial app domains will now be automatically setup during app creation.
- The `URLS` file containing generated urls for an app is no longer generated or referenced. Users should retrieve app urls via the new `domains-urls` plugin trigger.
- The common function `get_app_urls` has been removed. Users should retrieve app urls via the new `domains-urls` plugin trigger.
- Plugins should *not* call the `dokku` binary directly. Clients using the `--app` argument are potentially broken, amongst others, when doing so. Instead, please source the `functions` file for a given plugin when attempting to call Dokku internal functions. As a result, the following Dokku commands are no longer publicly exposed:
See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more information.
## (python) dokku-client
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
```shell
pip install dokku-client
```
See [documentation here](https://github.com/adamcharnock/dokku-client) for more information.
## (ruby) Dokku CLI
Dokku CLI is a rubygem that acts as a client for your Dokku installation. You can install it via the following shell command (assuming you have ruby and rubygems installed):
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>2</sup> Adds SQLite replication to external object storage via [Litestream](https://litestream.io)
<sup>3</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>4</sup> Adds the ability to sync an application repo with a remote Github repo (useful for automated rebuilds without needing a git push from an external system
<sup>4</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>5</sup> Adds the ability to invoke a post-deploy webhook with the IP, port and app name, all with a single config:set).
<sup>5</sup> Adds the ability to sync an application repo with a remote GitHub repo (useful for automated rebuilds without needing a git push from an external system
<sup>6</sup> Adds the ability to invoke a post-deploy webhook with the IP, port and app name, all with a single config:set).
| [PostgreSQL (single container)](https://github.com/jeffutter/dokku-postgresql-plugin) | [jeffutter][] | This plugin creates a single postgresql container that all your apps can use. Thus only one instance of postgresql running (good for servers without a ton of memory). |
| [RiakCS (single container)](https://github.com/jeffutter/dokku-riakcs-plugin) | [jeffutter][] | Incompatible with 0.2.0 (checked at [dccee02][]) |
<sup>1</sup> Forked from [jezdez/dokku-elasticsearch-plugin](https://github.com/jezdez/dokku-elasticsearch-plugin): uses Elasticsearch 1.2 (instead of 0.90), doesn't depend on dokku-link, runs as elasticsearch user instead of root, and turns off multicast autodiscovery for use in a VPS environment.
In order to leverage cloud-provider facilities like _attachable volumes_, (_a.k.a. block storage_)
the following is an easy tutorial to achieve Dokku runs on them.
> Warning: If the block storage is not available and attached on boot it is possible that containers will not correctly start. Please keep this in mind when considering moving Dokku and/or Docker to network attached storage.
## Tutorial
The following is intended to be executed on the dokku host machine as `root`.
Say, _for instance_, that our volume is mapped into the systems as `/dev/vdb1`.
Stop docker daemon
```shell
systemctl stop docker
```
Prepare the filesystem:
```shell
mkfs -t ext4 /dev/vdb1
mkdir /mnt/volume
mount /dev/vdb1 /mnt/volume
```
Move the old data directories:
```shell
mv /home/dokku /home/dokku.OLD
mv /var/lib/docker /var/lib/docker.OLD
mv /var/lib/dokku /var/lib/dokku.OLD
```
Move the data on the volume
```shell
mkdir /mnt/volume/home/
mkdir -p /mnt/volume/var/lib/
mv /home/dokku.OLD /mnt/volume/home/dokku
mv /var/lib/dokku.OLD /mnt/volume/var/lib/dokku
mv /var/lib/docker.OLD /mnt/volume/var/lib/docker
```
Prepare the mountpoints
```shell
mkdir /home/dokku
mkdir /var/lib/dokku
mkdir /var/lib/docker
chown dokku:dokku /home/dokku # respect the original ownership
chmod 711 /var/lib/docker # respect the original permissions
```
Mount bind
```shell
mount -o bind /mnt/volume/home/dokku /home/dokku
mount -o bind /mnt/volume/var/lib/dokku /var/lib/dokku
mount -o bind /mnt/volume/var/lib/docker /var/lib/docker
```
Start docker daemon
```shell
systemctl start docker
```
At this point all should be working fine, please check it out.
Then, let the changes be reboot-persistent
```shell
echo'/dev/vdb1 /mnt/volume ext4 defaults 0 2'| sudo tee -a /etc/fstab
echo'/mnt/volume/home/dokku /home/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/dokku /var/lib/dokku none defaults,bind 0 0'| sudo tee -a /etc/fstab
echo'/mnt/volume/var/lib/docker /var/lib/docker none defaults,bind 0 0'| sudo tee -a /etc/fstab
@@ -32,7 +32,6 @@ If an FQDN such as `dokku.org` is used as the application name, the global virtu
You can optionally override this in a plugin by implementing the `nginx-hostname` plugin trigger. If the `nginx-hostname` plugin has no output, the normal hostname algorithm will be executed. See the [plugin trigger documentation](/docs/development/plugin-triggers.md#nginx-hostname) for more information.
## Disabling VHOSTS
If desired, it is possible to disable vhosts with the domains plugin.
On subsequent deploys, the nginx virtualhost will be discarded. This is useful when deploying internal-facing services that should not be publicly routeable. As of 0.4.0, nginx will still be configured to proxy your app on some random high port. This allows internal services to maintain the same port between deployments. You may change this port by setting `DOKKU_PROXY_PORT` and/or `DOKKU_PROXY_SSL_PORT` (for services configured to use SSL.)
The domains plugin allows you to specify custom domains for applications. This plugin is aware of any ssl certificates that are imported via `certs:add`. Be aware that disabling domains (with `domains:disable`) will override any custom domains.
This is specific to your proxy plugin of choice. See the [nginx documentation](/docs/configuration/nginx.md#default-site) for more information on how to configure this for the default nginx proxy implementation.
This is specific to your proxy plugin of choice. See the [nginx documentation](/docs/networking/proxies/nginx.md#default-site) for more information on how to configure this for the default nginx proxy implementation.
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
config:unset [--no-restart] (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
```
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available *only* during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860).
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available _only_ during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860). Consider using [build arguments](/docs/deployment/builders/dockerfiles.md#build-time-configuration-variables) to expose variables during build-time for Dockerfile apps.
Environment variables are available both at run time and during the application build/compilation step for buildpack-based deploys.
For buildpack deploys, Dokku will create a `/app/.env` file that can be used for legacy buildpacks. Note that this is *not* updated when `config:set` or `config:unset` is called, and is only written during a `deploy` or `ps:rebuild`. Developers are encouraged to instead read from the application environment directly, as the proper values will be available then.
For buildpack deploys, Dokku will create a `/app/.env` file that can be used for legacy buildpacks. Note that this is _not_ updated when `config:set` or `config:unset` is called, and is only written during a `deploy` or `ps:rebuild`. Developers are encouraged to instead read from the application environment directly, as the proper values will be available then.
> Note: Global `ENV` files are sourced before app-specific `ENV` files. This means that app-specific variables will take precedence over global variables. Configuring your global `ENV` file is manual, and should be considered potentially dangerous as configuration applies to all applications.
@@ -91,11 +91,11 @@ The following config variables have special meanings and can be set in a variety
| `DOKKU_EVENTS_LOGFILE` | `$DOKKU_LOGS_DIR/events.log` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Where the events log file is written to. |
| `DOKKU_APP_NAME` | none | `--app APP` flag | Name of application to work on. Respected by core plugins. |
| `DOKKU_APPS_FORCE_DELETE` | none | `--force` flag | Whether to force delete an application. Also used by other plugins for destructive actions. |
| `DOKKU_CHECKS_URL` | `https://dokku.com/docs/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Whether to detach a container started via `dokku run`. |
| `DOKKU_CHECKS_URL` | `https://dokku.com/docs/deployment/zero-downtime-deploys/` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*`| Url displayed during deployment when no CHECKS file exists. |
| `DOKKU_DETACH_CONTAINER` | none | `--detach` flag | Deprecated: Whether to detach a container started via `dokku run`. |
| `DOKKU_QUIET_OUTPUT` | none | `--quiet` flag | Silences certain header output for `dokku` commands. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> `--rm-container` flag <br /> `--rm` flag | Whether to keep `dokku run` containers around or not. |
| `DOKKU_TRACE` | none | `dokku trace:on` <br /> `dokku trace:off` <br /> `--trace` flag | Turn on very verbose debugging. |
| `DOKKU_RM_CONTAINER` | none | `dokku config:set` <br /> | Deprecated: Whether to keep `dokku run` containers around or not. |
| `DOKKU_TRACE` | none | `dokku trace:on` <br /> `dokku trace:off` <br /> `--trace` flag | Turn on very verbose debugging. |
| `DOKKU_APP_SHELL` | `/bin/bash` | `dokku config:set` | Allows users to change the default shell used by Dokku for `dokku enter` and execution of deployment tasks. |
@@ -125,4 +125,3 @@ The following config variables have special meanings and can be set in a variety
| `DOKKU_START_CMD` | none | `dokku config:set` | Command to run instead of `/start $PROC_TYPE` |
| `DOKKU_SYSTEM_GROUP` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System group to chown files as. |
| `DOKKU_SYSTEM_USER` | `dokku` | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | System user to chown files as. |
| `DOKKU_WAIT_TO_RETIRE` | `60` | `dokku config:set` | After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections. |
When an SSL certificate is associated to an application, the certificate will be associated with *all* domains currently associated with said application. Your certificate _should_ be associated with all of those domains, otherwise accessing the application will result in SSL errors. If you wish to remove one of the domains from the application, refer to the [domain configuration documentation](/docs/configuration/domains.md).
When an SSL certificate is associated to an application, the certificate will be associated with _all_ domains currently associated with said application. Your certificate _should_ be associated with all of those domains, otherwise accessing the application will result in SSL errors. If you wish to remove one of the domains from the application, refer to the [domain configuration documentation](/docs/configuration/domains.md).
Note that with the default nginx template, requests will be redirected to the `https` version of the domain. If this is not the desired state of request resolution, you may customize the nginx template in use. For more details, see the [nginx documentation](/docs/configuration/nginx.md).
Note that with the default nginx template, requests will be redirected to the `https` version of the domain. If this is not the desired state of request resolution, you may customize the nginx template in use. For more details, see the [nginx documentation](/docs/networking/proxies/nginx.md).
The [HSTS header](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) is an HTTP header that can inform browsers that all requests to a given site should be made via HTTPS. Dokku does enables this header by default for HTTPS requests.
See the [NGINX HSTS documentation](/docs/configuration/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
See the [NGINX HSTS documentation](/docs/networking/proxies/nginx.md#hsts-header) for more information on how the HSTS configuration can be managed for your application.
> Note: This walkthrough uses the hostname `dokku.me` in commands. When deploying to your own server, you should substitute the domain `dokku.me` for the domain name or IP address associated with your server. Users of the Vagrant VM included with Dokku can use `dokku.me` which points to the IP of the VM.
@@ -105,7 +105,7 @@ Dokku supports deploying applications in a few ways:
- [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) to learn about the different ways to specify a buildpack.
- This is the default method used by Dokku.
- [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/builders/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/images.md) to learn about how to deploy a Docker Image.
- [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) to learn about how to deploy a Docker Image.
@@ -240,7 +242,7 @@ See the [Dockerfile documentation](/docs/deployment/builders/dockerfiles.md) for
## Image tagging
See the [image tagging documentation](/docs/deployment/methods/images.md) for more information on how Docker images can be tagged and deployed for a given application.
See the [image tagging documentation](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) for more information on how Docker images can be tagged and deployed for a given application.
Remember to also change your git remote on your local machine in order to make `git push dokku main:master` work again. For this you can use `git remote set-url`.
If you wish to disable deploying for a period of time, this can be done via deploy locks. Normally, deploy locks exist only for the duration of a deploy so as to avoid deploys from colliding, but a deploy lock can be created by running the `apps:lock` command.
```shell
dokku apps:lock node-js-app
```
@@ -224,7 +229,6 @@ dokku apps:unlock node-js-app
In some cases, you may wish to inspect the state of an app lock. To do so, you can issue an `apps:lock` command. This will exit non-zero if there is no app lock in place.
@@ -17,6 +17,8 @@ Dokku supports the following built-in builders:
-`builder-dockerfile`: Builds apps using a `Dockerfile` via `docker build`. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how this builder functions.
-`builder-herokuish`: Builds apps with Heroku's v2a Buildpack specification via `gliderlabs/herokuish`. See the [herokuish builder documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how this builder functions.
-`builder-lambda`: Builds AWS Lambda functions in an environment simulating AWS Lambda runtimes via [lambda-builder](https://github.com/dokku/lambda-builder). See the [lambda builder documentation](/docs/deployment/builders/lambda.md) for more information on how this builder functions.
-`builder-null`: Does nothing during the build phase. See the [null builder documentation](/docs/deployment/builders/null.md) for more information on how this builder functions.
-`builder-pack`: Builds apps with Cloud Native Buildpacks via the `pack-cli` tool. See the [cloud native buildpacks builder documentation](/docs/deployment/builders/cloud-native-buildpacks.md) for more information on how this builder functions.
Builders run a detection script against a source code repository, and the first detected builder will be used to build the app artifact. The exception to this is when a `Dockerfile` is detected and the app is also able to use either `herokuish` or `pack-cli` for building, in which case one of the latter will be chosen.
@@ -47,6 +49,34 @@ The default value may be set by passing an empty value for the option.
dokku builder:set --global selected
```
#### Changing the build directory
> Warning: Please keep in mind that setting a custom build directory will result in loss of any changes to the top-level directory, such as the `git.keep-git-dir` property.
When deploying a monorepo, it may be desirable to specify the specific build directory to use for a given app. This can be done via the `builder:set` command. If a value is specified and that directory does not exist within the repository, the build will fail.
```shell
dokku builder:set node-js-app build-dir app2
```
The default value may be set by passing an empty value for the option:
```shell
dokku builder:set node-js-app build-dir
```
The `build-dir` property can also be set globally. The global default is empty string, and the global value is used when no app-specific value is set.
```shell
dokku builder:set --global build-dir app2
```
The default value may be set by passing an empty value for the option.
```shell
dokku builder:set --global build-dir
```
### Displaying builder reports for an app
You can get a report about the app's builder status using the `builder:report` command:
- A `.project.toml` file exists in the root of the app repository.
- This file is consumed by `pack-cli` and used to describe how the app is built.
The builder can also be specified via the `builder:set` command:
```shell
dokku builder:set node-js-app selected pack
```
> Dokku will only select the `dockerfile` builder if both the `herokuish` and `pack` builders are not detected and a Dockerfile exists. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how that builder functions.
### Requirements
The `pack` cli tool is not included by default with Dokku or as a dependency. It must also be installed as shown on [this page](https://buildpacks.io/docs/tools/pack/).
@@ -51,6 +37,99 @@ As this functionality is highly experimental, there are a number of caveats. Ple
-`pack` is not currently included with Dokku, nor is it added as a package dependency.
- A future version will include it as a package dependency.
### Detection
This builder will be auto-detected in either the following cases:
- The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
- A `project.toml` file exists in the root of the app repository.
- This file is consumed by `pack-cli` and used to describe how the app is built.
The builder can also be specified via the `builder:set` command:
```shell
dokku builder:set node-js-app selected pack
```
> Dokku will only select the `dockerfile` builder if both the `herokuish` and `pack` builders are not detected and a Dockerfile exists. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how that builder functions.
### Changing the `project.toml` location
When deploying a monorepo, it may be desirable to specify the specific path of the `project.toml` file to use for a given app. This can be done via the `builder-pack:set` command. If a value other than `project.toml` is specified and that file does not exist in the app's build directory, Dokku will continue the build process as if the repository has no `project.toml`.
The `projecttoml-path` property can also be set globally. The global default is `project.toml`, and the global value is used when no app-specific value is set.
A change in the stack builder value will execute the `post-stack-set` trigger.
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_CNB_STACK` environment variable (`heroku/buildpacks` by default).
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_CNB_BUILDER` environment variable (`heroku/buildpacks` by default).
builder-dockerfile:report [<app>] [<flag>] # Displays a builder-dockerfile report for one or more apps
builder-dockerfile:set <app> <key> (<value>) # Set or clear a builder-dockerfile property for an app
```
While Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, you can also use Docker's native `Dockerfile` system to define a container.
> Dockerfile support is considered a *power user* feature. By using Dockerfile-based deployment, you agree that you will not have the same comfort as that enjoyed by buildpack users, and Dokku features may work differently. Differences between the two systems will be documented here.
@@ -27,22 +32,92 @@ If an application was previously deployed via buildpacks, the following commands
> The previous method to perform this - via `docker-options:add` - should be removed in favor of the `builder-dockerfile:set` command outlined here.
When deploying a monorepo, it may be desirable to specify the specific path of the `Dockerfile` file to use for a given app. This can be done via the `builder-dockerfile:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
The `dockerfile-path` property can also be set globally. The global default is `Dockerfile`, and the global value is used when no app-specific value is set.
For security reasons - and as per [Docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available only during runtime.
For users that require customization in the `build` phase, you may use build arguments via the [docker-options plugin](docs/advanced-usage/docker-options.md):
For users that require customization in the `build` phase, you may use build arguments via the [docker-options plugin](/docs/advanced-usage/docker-options.md):
The location of the `Dockerfile` may also be specified. If the location is changed, the repository **must also** have a `Dockerfile` in the root directory in order to trigger a dockerfile-based deploy.
Once set, the Dockerfile usage would be as follows:
```Dockerfile
@@ -75,7 +150,29 @@ RUN echo $NODE_ENV
### Building images with Docker Buildkit
If your Dockerfile is using Docker engine's [buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set. One way to do this is to edit `/etc/environment` on your dokku host and reboot your instance. Note, for complete build log output, you should also set`BUILDKIT_PROGRESS=plain` in the same file.
If your Dockerfile is using Docker engine's [buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set. Additionally, complete build log output can be forced via`BUILDKIT_PROGRESS=plain`. Both of these environment variables can be set as follows:
```shell
echo"export DOCKER_BUILDKIT=1"| sudo tee -a /etc/default/dokku
echo"export BUILDKIT_PROGRESS=plain"| sudo tee -a /etc/default/dokku
```
#### Buildkit directory caching
Buildkit implements the `RUN --mount` option, enabling mount directory caches for `RUN` directives. The following is an example that mounts debian packaging related directories, which can speed up fetching of remote package data.
```Dockerfile
FROMdebian:latest
RUN --mount=target=/var/lib/apt/lists,type=cache \
Mount cache targets may vary depending on the tool in use, and users are encouraged to investigate the directories that apply for their language and framework.
You would adjust the cache directory for whatever application cache you have, e.g. `/root/.pnpm-store/v3` for pnpm, `$HOME/.m2` for maven, or `/root/.cache` for golang.
@@ -12,6 +12,11 @@ buildpacks:set [--index 1] <app> <buildpack> # Set new app buildpack
buildpacks:set-property [--global|<app>] <key> <value> # Set or clear a buildpacks property for an app
```
```
builder-herokuish:report [<app>] [<flag>] # Displays a builder-herokuish report for one or more apps
builder-herokuish:set <app> <key> (<value>) # Set or clear a builder-herokuish property for an app
```
> Warning: If using the `buildpacks` plugin, be sure to unset any `BUILDPACK_URL` and remove any such entries from a committed `.env` file. A specified `BUILDPACK_URL` will always override a `.buildpacks` file or the buildpacks plugin.
Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
A change in the stack builder value will execute the `post-stack-set` trigger.
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_IMAGE` environment variable (`gliderlabs/herokuish:latest` by default).
Finally, stack builders can be set or unset globally as a fallback. This will take precedence over a globally set `DOKKU_IMAGE` environment variable (`gliderlabs/herokuish:latest-20` by default).
By default, the builder-herokuish plugin is not enabled for non-amd64 platforms, and attempting to use it is blocked. This is because the majority of buildpacks are not cross-platform compatible, and thus building apps will either be considerably slower - due to emulating the amd64 platform - or won't work - due to building amd64 packages on arm/arm64 platforms.
To force-enable herokuish on non-amd64 platforms, the `allowed` property can be set via `builder-herokuish:set`. The default value depends on the host platform architecture (`true` on amd64, `false` otherwise).
The default value may be set by passing an empty value for the option:
```shell
dokku builder-herokuish:set node-js-app allowed
```
The `allowed` property can also be set globally. The global default is platform-dependent, and the global value is used when no app-specific value is set.
```shell
dokku builder-herokuish:set --global allowed true
```
The default value may be set by passing an empty value for the option.
```shell
dokku builder-herokuish:set --global allowed
```
### Displaying buildpack reports for an app
You can get a report about the app's buildpacks status using the `buildpacks:report` command:
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
By default, Dokku uses the [gliderlabs/herokuish](https://github.com/gliderlabs/herokuish/) project, which pins all of it's vendored buildpacks. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified *without* a Git commit SHA like so:
By default, Dokku uses the [gliderlabs/herokuish](https://github.com/gliderlabs/herokuish/) project, which pins all of it's vendored buildpacks. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified _without_ a Git commit SHA like so:
The `web` process type holds some significance in that it is the only process type that is automatically scaled to `1` on the initial application deploy. See the [process scaling documentation](/docs/processes/process-management.md) for more details around scaling individual processes.
### `curl` build timeouts
Certain buildpacks may time out in retrieving dependencies via `curl`. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a `curl` command.
builder-lambda:report [<app>] [<flag>] # Displays a builder-lambda report for one or more apps
builder-lambda:set <app> <key> (<value>) # Set or clear a builder-lambda property for an app
```
The `lambda` builder builds AWS Lambda functions in an environment simulating AWS Lambda runtimes via [lambda-builder](https://github.com/dokku/lambda-builder). Apps built via this builder can run natively in Dokku and may also have their artifacts scheduled to Lambda via an appropriate scheduler.
## Usage
### Detection
This builder will be auto-detected in the following case:
- A `lambda.yml` exists in the root of the app repository.
The builder may also be selected via the `builder:set` command
```shell
dokku builder:set node-js-app selected lambda
```
### Supported languages
The `lambda` builder plugin supports the following AWS runtime languages on Amazon Linux 2:
- dotnet
- go (builder is based on AL1)
- nodejs
- python
- ruby
See the [lambda-builder](https://github.com/dokku/lambda-builder#how-does-it-work) documentation for more information on how specific languages are detected.
### Customizing the build environment
The `lambda` builder plugin delegates all build logic to [lambda-builder](https://github.com/dokku/lambda-builder), including language detection and build/runtime environment specification. The lambda-builder tool supports a `lambda.yml` file format for customizing how apps are built. Please see the readme for lambda-builder for more information on different options.
### Changing the `lambda.yml` location
When deploying a monorepo, it may be desirable to specify the specific path of the `lambda.yml` file to use for a given app. This can be done via the `builder-lambda:set` command. If a value is specified and that file does not exist in the app's build directory, then the build will fail.
The `lambdayml-path` property can also be set globally. The global default is `lambda.yml`, and the global value is used when no app-specific value is set.
The `null` builder does nothing, and is useful for routing to services not managed by Dokku. It should not be used in normal operation. Please see the [network documentation](/docs/networking/network.md#routing-an-app-to-a-known-ip:port-combination) for more information on the aforementioned use case.
## Usage
### Detection
This builder is _never_ auto-detected. The builder _must_ be specified via the `builder:set` command:
```shell
dokku builder:set node-js-app selected null
```
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.