# 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.
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?
> 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 configure your server domain (via `dokku domains:set-global`) and user access (via `dokku ssh-keys:add`) to complete the installation.
@@ -112,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 [Gliderlabs Slack in the #dokku channel](https://glider-slackin.herokuapp.com/).
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 [Gliderlabs Slack in the #dokku channel](https://glider-slackin.herokuapp.com/), 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.
@@ -17,30 +17,30 @@ To support this, Dokku provides support for a special `release` command within y
Each "phase" has different expectations and limitations:
-`app.json`: `scripts.dokku.predeploy`
- When to use: This should be used if your app does not support arbitrary build commands and you need to make changes to the built image.
- Are changes committed to the image at this phase: Yes
- Example use-cases
- Bundling assets in a slightly different way
- Installing a custom package from source or copying a binary into place
- When to use: This should be used if your app does not support arbitrary build commands and you need to make changes to the built image.
- Are changes committed to the image at this phase: Yes
- Example use-cases
- Bundling assets in a slightly different way
- Installing a custom package from source or copying a binary into place
-`app.json`: `scripts.dokku.postdeploy`
- When to use: This should be used in conjunction with external systems to signal the completion of your deploy.
- Are changes committed to the image at this phase: No
- Example use-cases
- Notifying slack that your app is deployed
- Coordinating traffic routing with a central load balancer
- When to use: This should be used in conjunction with external systems to signal the completion of your deploy.
- Are changes committed to the image at this phase: No
- Example use-cases
- Notifying slack that your app is deployed
- Coordinating traffic routing with a central load balancer
-`app.json`: `scripts.postdeploy`
- When to use: This should be used when you wish to run a command _once_, after the app is created and not on subsequent deploys to the app.
- Are changes committed to the image at this phase: No
- Example use-cases
- Setting up OAuth clients and DNS
- Loading seed/test data into the app’s test database
- When to use: This should be used when you wish to run a command _once_, after the app is created and not on subsequent deploys to the app.
- Are changes committed to the image at this phase: No
- Example use-cases
- Setting up OAuth clients and DNS
- Loading seed/test data into the app’s test database
-`Procfile`: `release`
- When to use: This should be used in conjunction with external systems to signal the completion of your app image build.
- Are changes committed to the image at this phase: No
- Example use-cases
- Sending CSS, JS, and other assets from your app’s slug to a CDN or S3 bucket
- Priming or invalidating cache stores
- Running database migrations
- When to use: This should be used in conjunction with external systems to signal the completion of your app image build.
- Are changes committed to the image at this phase: No
- Example use-cases
- Sending CSS, JS, and other assets from your app’s slug to a CDN or S3 bucket
- Priming or invalidating cache stores
- Running database migrations
Additionally, if using a Dockerfile with an `ENTRYPOINT`, the deployment task is passed to that entrypoint as is. The exceptions are if the entrypoint is one of the following:
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.
## App User and Persistent Storage file ownership (buildpack apps only)
@@ -175,4 +175,4 @@ By default, Dokku will execute your buildpack app processes as the `herokuishuse
> 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.
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.
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.
@@ -7,7 +7,9 @@ The [dokku-registry](https://github.com/dokku/dokku-registry) plugin is now buil
- 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/deployment/registry-management.md) for more details.
- 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.
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.
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):
@@ -116,13 +118,15 @@ The following plugins are available and provided by Dokku maintainers. Please f
<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).
### Other Plugins
@@ -238,6 +242,7 @@ The following plugins are no longer maintained by their developers.
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
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.
@@ -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).
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.
### Setting up SSL
@@ -242,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`.
@@ -17,6 +17,7 @@ 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.
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.
Builderdockerfile global dockerfile path: Dockerfile
Builderdockerfile dockerfile path: Dockerfile2
```
You can pass flags which will output only the value of the specific information you want. For example:
@@ -107,7 +112,7 @@ Dockerfile2
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):
@@ -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:
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:
@@ -211,6 +246,54 @@ You can pass flags which will output only the value of the specific information
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.
logs:failed [--all|<app>] # Shows the last failed deploy logs
logs:report [<app>] [<flag>] # Displays a logs report for one or more apps
logs:set [--global|<app>] <key> <value> # Set or clear a logs property for an app
@@ -20,6 +20,8 @@ You can easily get logs of an app using the `logs` command:
dokku logs node-js-app
```
Logs are pulled via integration with the scheduler for the specified application via "live tailing". As such, logs from previously running deployments are usually not available. Users that desire to see logs from previous deployments for debugging purposes should persist those logs to external services. Please see Dokku's [vector integration](/docs/deployment/logs.md#vector-logging-shipping) for more information on how to persist logs across deployments to ship logs to another service or a third-party platform.
#### Behavioral modifiers
Dokku also supports certain command-line arguments that augment the `log` command's behavior.
@@ -41,7 +43,7 @@ The above command will show logs continually from the web process.
### Failed deploy logs
> Warning: The default [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md) will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
> Warning: The default [docker-local scheduler](/docs/deployment/schedulers/docker-local.md) will "store" these until the next deploy or until the old containers are garbage collected - whichever runs first. If you require the logs beyond this point in time, please ship the logs to a centralized log server.
In some cases, it may be useful to retrieve the logs from a previously failed deploy.
git:public-key # Outputs the dokku public deploy key
git:report [<app>] [<flag>] # Displays a git report for one or more apps
git:set <app> <key> (<value>) # Set or clear a git property for an app
git:status <app> # Show the working tree status for an app
git:unlock <app> [--force] # Removes previous git clone folder for new deployment
```
@@ -135,6 +136,8 @@ In the above example, Dokku will build the app as if the repository contained _o
FROMdokku/node-js-getting-started:latest
```
If the specified image already exists on the Dokku host, it will not be pulled again, though this behavior may be changed using [build phase docker-options](/docs/advanced-usage/docker-options.md).
Triggering a build with the same arguments multiple times will result in Dokku exiting `0` early as there will be no changes detected. If the image tag is reused but the underlying image is different, it is recommended to use the image digest instead of the tag. This can be retrieved via the following command:
If the image is a private image that requires a docker login to access, the `registry:login` command should be used to log into the registry. See the [registry documentation](/docs/advanced-usage/registry-management.md#logging-into-a-registry) for more details on this process.
Building an app from an image will result in the following files being extracted from the source image (with all custom paths specified for each file being respected):
- nginx.conf.sigil
- Procfile
In the case where the repository is later modified to manually add any of the above files and deployed via `git push`, the files will still be extracted from the initial source image. To avoid this, please clear the `source-image` git property. It will be set back to the original source image on any subsequent `git:from-image` calls.
```shell
# sets an empty value
dokku git:set node-js-app source-image
```
Finally, certain images may require a custom build context in order for `ONBUILD ADD` and `ONBUILD COPY` statements to succeed. A custom build context can be specified via the `--build-dir` flag. All files in the specified `build-dir` will be copied into the repository for use within the `docker build` process. The build context _must_ be specified on each deploy, and is not otherwise persisted between builds.
Dokku commands can be run over SSH. Anywhere you would run `dokku <command>`, just run `ssh -t dokku@dokku.me <command>`
The `-t` is used to request a pty. It is highly recommended to do so.
To avoid the need to type the `-t` option each time, simply create/modify a section in the `.ssh/config` on the client side, as follows:
To avoid the need to type the `-t` option each time, create/modify a section in the `.ssh/config` on the client side, as follows:
```ini
Host dokku.me
@@ -12,7 +12,7 @@ Host dokku.me
## Behavioral modifiers
Dokku also supports certain command line arguments that augment its behavior. If using these over SSH, you must use the form `ssh -t dokku@dokku.me -- <command>`
in order to avoid SSH interpretting Dokku arguments for itself.
to avoid SSH interpreting Dokku arguments for itself.
```
--quiet suppress output headers
@@ -71,7 +71,7 @@ All commands have the application name automatically set via the `--app` flag on
The client supports several environment variables:
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overriden via `--remote` flag.
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overridden via the `--remote` flag.
-`DOKKU_PORT` (default: `22`): Used to specify a port to connect to the Dokku server on.
It also supports several flags (all flags unspecified here are passed as is to the server):
@@ -84,10 +84,10 @@ It also supports several flags (all flags unspecified here are passed as is to t
In addition, the following commands have special local side-effects:
-`apps:create`:
- If no local `--app` flag is specified or detected from a `dokku` git remote, a random name is generated and used for the app.
- The `dokku` git remote is set if not already set.
- If no local `--app` flag is specified or detected from a `dokku` git remote, a random name is generated and used for the app.
- The `dokku` git remote is set if not already set.
The `scheduler-docker-local` injects an init process by default via the `--init`. For some apps - such as those where the built docker image uses S6 as the init - this may be undesirable and cause issues with process starts. You may disable this by running the following `scheduler-docker-local:set` command for your application:
All image containers with the label `org.opencontainers.image.vendor=linuxserver.io` will have the automatic init process injection force-disabled without further intervention.
### Deploying Process Types in Parallel
> New as of 0.25.5
@@ -91,7 +107,11 @@ Omitting or removing the entry will result in parallelism for that process type
Note that increasing the value of `max_parallel` may significantly impact CPU utilization on your host as your app containers - and their respective processes - start up. Setting a value higher than the number of available CPUs is discouraged. It is recommended that users carefully set this value so as not to overburden their server.
## Implemented Triggers
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `docker-local` scheduler.
### Implemented Commands and Triggers
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.
@@ -105,22 +125,27 @@ This plugin implements various functionality through `plugn` triggers to integra
-`ps:stop`
-`run`
## Supported Resource Management Properties
### Logging support
App logs for the `logs` command are fetched from running containers via the `docker` cli. To persist logs across deployments, consider using Dokku's [vector integration](/docs/deployment/logs.md#vector-logging-shipping) to ship logs to another service or a third-party platform.
### Supported Resource Management Properties
The `docker-local` scheduler supports a minimal list of resource _limits_ and _reservations_. The following properties are supported:
### Resource Limits
#### 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).
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
- 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
#### Resource Reservations
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
> Warning: This scheduler is not in Dokku core and thus is considered experimental.
> Warning: This scheduler is not in Dokku core and thus functionality may change over time as the API stabilizes.
The [Kubernetes Scheduler Plugin](https://github.com/dokku/dokku-scheduler-kubernetes) implements the following functionality:
The [Kubernetes Scheduler Plugin](https://github.com/dokku/dokku-scheduler-kubernetes) is available free as an external plugin. Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-kubernetes/issues) for more information on the status of the plugin.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `kubernetes` scheduler.
### Implemented Commands and Triggers
This plugin implements various functionality through `plugn` triggers to integrate with `kubectl` for running apps on a Kubernetes cluster. The following functionality is supported by the `scheduler-kubernetes` plugin.
-`apps:destroy`
-`deploy`: partial, does not implement failed deploy log capture
-`logs`: partial, does not implement failure logs
-`ps:stop`
Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-kubernetes/issues) for more information on the status of the plugin.
### Logging support
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
App logs for the `logs` command are fetched from running pods via the `kubectl` cli. To persist logs across deployments, consider using [Vector](https://vector.dev/docs/setup/installation/platforms/kubernetes/) or a similar tool to ship logs to another service or a third-party platform.
> Warning: This scheduler is not in Dokku core and thus is considered experimental.
> Warning: This scheduler is not in Dokku core and thus functionality may change over time as the API stabilizes.
The [Nomad Scheduler Plugin](https://github.com/dokku/dokku-scheduler-nomad) implements the following functionality:
The [Nomad Scheduler Plugin](https://github.com/dokku/dokku-scheduler-nomad) is available free as an external plugin. Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-nomad/issues) for more information on the status of the plugin.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `nomad` scheduler.
### Implemented Commands and Triggers
This plugin implements various functionality through `plugn` triggers to integrate with the `nomad` cli for running apps on a Nomad cluster. The following functionality is supported by the `scheduler-nomad` plugin.
-`apps:destroy`
-`deploy`
-`ps:stop`
Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-nomad/issues) for more information on the status of the plugin.
### Logging support
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
> Warning: Fetching app logs for the `logs` command is currently not implemented. Please consider using [Vector](https://vector.dev/docs/setup/installation/platforms/kubernetes/) or a similar tool to ship logs to another service or a third-party platform.
@@ -18,8 +18,6 @@ Dokku supports the following built-in schedulers:
-`scheduler-docker-local`: Schedules apps against the local docker socket and runs containers directly on the Dokku host. See the [docker-local scheduler documentation](/docs/deployment/schedulers/docker-local.md) for more information on how this scheduler functions.
-`scheduler-null`: Does nothing during the scheduler phase. See the [null scheduler documentation](/docs/deployment/schedulers/null.md) for more information on how this scheduler functions.
See the [alternate schedulers documentation](/docs/deployment/schedulers/alternate-schedulers.md) for more information on other scheduler plugins.
### Overriding the auto-selected scheduler
If desired, the scheduler can be specified via the `scheduler:set` command by speifying a value for `selected`. The selected scheduler will always be used.
checks:disable <app> [process-type(s)] Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
checks:enable <app> [process-type(s)] Enable zero-downtime deployment for all processes (or comma-separated process-type list)
checks:report [<app>] [<flag>] Displays a checks report for one or more apps
checks:run <app> [process-type(s)] Runs zero-downtime checks for all processes (or comma-separated process-type list)
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
checks:disable <app> [process-type(s)] Disable zero-downtime deployment for all processes (or comma-separated process-type list) ***WARNING: this will cause downtime during deployments***
checks:enable <app> [process-type(s)] Enable zero-downtime deployment for all processes (or comma-separated process-type list)
checks:report [<app>] [<flag>] Displays a checks report for one or more apps
checks:run <app> [process-type(s)] Runs zero-downtime checks for all processes (or comma-separated process-type list)
checks:set [--global|<app>] <key> <value> Set or clear a logs property for an app
checks:skip <app> [process-type(s)] Skip zero-downtime checks for all processes (or comma-separated process-type list)
```
By default, Dokku will wait `10` seconds after starting each container before assuming it is up and proceeding with the deploy. Once this has occurred for all containers started by an application, traffic will be switched to point to your new containers. Dokku will also wait a further `60` seconds *after* the deploy is complete before terminating old containers in order to give time for long running connections to terminate. In either case, you may have more than one container running for a given application.
@@ -22,13 +23,24 @@ You may both create user-defined checks for web processes using a `CHECKS` file,
> - Allow checks from all hostnames: Modify your application to accept a dynamically provided hostname.
> - Specify the domain within the check: See below for further documentation.
## Configuring checks settings
### wait-to-retire
After a successful deploy, the grace period given to old containers before they are stopped/terminated is determined by the value of `wait-to-retire`. This is useful for ensuring completion of long-running HTTP connections.
```shell
dokku checks:set node-js-app wait-to-retire 30
```
Defaults to `60`.
## Configuring check settings using the `config` plugin
There are certain settings that can be configured via environment variables:
-`DOKKU_DEFAULT_CHECKS_WAIT`: (default: `10`) If no user-defined checks are specified - or if the process being checked is not a `web` process - this is the period of time Dokku will wait before checking that a container is still running.
-`DOKKU_DOCKER_STOP_TIMEOUT`: (default: `10`) Configurable grace period given to the `docker stop` command. If a container has not stopped by this time, a `kill -9` signal or equivalent is sent in order to force-terminate the container. Both the `ps:stop` and `apps:destroy` commands *also* respect this value. If not specified, the Docker defaults for the [`docker stop` command](https://docs.docker.com/engine/reference/commandline/stop/) will be used.
-`DOKKU_WAIT_TO_RETIRE`: (default: `60`) 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.
The following settings may also be specified in the `CHECKS` file, though are available as environment variables in order to ease application reuse.
- Description: Allows modification of the used dokku-image.
@@ -206,6 +221,36 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `builder-image-is-cnb`
- Description: Checks if an image is cnb-based
- Invoked by: unit tests
- Arguments: `$APP``$IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `builder-image-is-herokuish`
- Description: Checks if an image is herokuish-based
- Invoked by: unit tests
- Arguments: `$APP``$IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `builder-release`
- Description: Triggers the artifact release process
@@ -221,6 +266,21 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `certs-exists`
- Description: Echos `true` if certs exists for the app, `false` otherwise
- Invoked by:
- Arguments: `$APP`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `check-deploy`
- Description: Allows you to run checks on a deploy before Dokku allows the container to handle requests.
@@ -247,6 +307,22 @@ if [[ "$DOKKU_DISABLE_DEPLOY" = "true" ]]; then
fi
```
### `checks-get-property`
- Description: Return the value for an app's checks property
- Invoked by:
- Arguments: `$APP $KEY`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";PROPERTY="$2"
# TODO
```
### `commands help` and `commands <PLUGIN_NAME>:help`
- Description: Your plugin should implement a `help` command in your `commands` file to take advantage of this plugin trigger. `commands help` is used by `dokku help` to aggregate all plugins abbreviated `help` output. Implementing `<PLUGIN_NAME>:help` in your `commands` file gives users looking for help, a more detailed output. 'commands help' must be implemented inside the `commands` plugin file. It's recommended that `PLUGIN_NAME:help` be added to the commands file to ensure consistency among community plugins and give you a new avenue to share rich help content with your user.
> Warning: The scheduler plugin trigger apis are under development and may change
@@ -2367,3 +2513,44 @@ shift 2
[["$SSH_NAME"=="default"&&$1== plugin:* ]]&&exit1
exit0
```
### `user-auth-app`
This is a special plugin trigger that is executed when listing apps or checking if an app exists. All Dokku commands should check if an app exists at least once before interacting with them so as not to circumvent the check.
Note that the trigger should exit `0`, and each non-empty line on stdout is captured as a valid app name.
The `SSH_USER` is the original ssh user. If you are running remote commands, this user will typically be `dokku`, and as such should not be trusted when checking permissions. If you are connected via ssh as a different user who then invokes `dokku`, the value of this variable will be that user's name (`root`, `myuser`, etc.).
The `SSH_NAME` is the `NAME` variable set via the `sshcommand acl-add` command. For reference, the following command can be run as the root user to specify a specific `NAME` for a given ssh key:
```shell
sshcommand acl-add dokku NAME < $PATH_TO_SSH_KEY
```
Note that the `NAME` value is set at the first ssh key match. If an ssh key is set in the `/home/dokku/.ssh/authorized_keys` multiple times, the first match will decide the value.
- Description: Allows you to deny access to a Dokku app by either ssh user or associated ssh-command NAME user.
- Invoked by: `dokku`
- Arguments: `$SSH_USER $SSH_NAME $DOKKU_COMMAND`
- Example:
```shell
#!/usr/bin/env bash
# hide any apps with the prefix "admin"
# if the logged in user (SSH_USER) or SSH_NAME is not `root`
> **Warning:** Web installer is not available on CentOS. You will need to configure [SSH keys](/docs/deployment/user-management.md#adding-ssh-keys) and [virtual hosts](/docs/configuration/domains.md#customizing-hostnames) using dokku command line interface.
Dokku defaults to being installed via RPM package on CentOS 7. While certain hosts may require extra work to get running, you may optionally wish to automate the installation of Dokku without the use of our `bootstrap.sh` Bash script. The following are the steps run by said script:
The [devicemapper](https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/) is the default Docker storage driver on CentOS 7 and defaults to a configuration mode known as `loop-lvm`. This mode is designed to work out-of-the-box with no additional configuration. However, production deployments should not run under `loop-lvm` mode. The preferred configuration for production deployments is [`direct-lvm`](https://docs.docker.com/engine/userguide/storagedriver/device-mapper-driver/#/configure-direct-lvm-mode-for-production).
- A server with one of the following architectures
- AMD64 (alternatively known as `x86_64`), commonly used for Intel cloud servers
- ARMV7 (alternatively known as `armhf`), commonly used for Raspberry PI
- ARMV8 (alternatively known as `arm64`), commonly used for Raspberry PI and AWS Graviton
To avoid memory pressure during builds or runtime of your applications, we suggest the following:
- At least 1 GB of system memory
- If your system has less than 1GB of memory, you can use [this workaround](/docs/getting-started/advanced-installation.md#vms-with-less-than-1gb-of-memory).
- If your system has less than 1GB of memory, you can use [this workaround](/docs/getting-started/advanced-installation.md#vms-with-less-than-1-gb-of-memory).
Finally, we recommend attaching at least one domain name to your server. This is not required, but using a domain name will make app access easier. When connecting a domain, either a single domain or a wildcard may be associated to the server's IP.
@@ -38,8 +38,8 @@ To install the latest stable version of Dokku, you can run the following shell c
If your version of Dokku is pre 0.3.0 (check with `dokku version`), we recommend [a fresh install](/docs/getting-started/installation.md) on a new server.
If your version of Dokku is pre 0.3.0 (check with `dokku version`), we recommend [a fresh install](/docs/getting-started/installation/index.md) on a new server.
## Security Updates
@@ -9,7 +9,6 @@ For any security related updates, please follow our [Twitter account](https://tw
Your operating system may occasionally provide security updates. We recommend setting unattended upgrades for your operating system. Here are some helpful links:
- [Arch Linux System Maintenance](https://wiki.archlinux.org/index.php/System_maintenance)
@@ -20,9 +20,19 @@ GitHub Discussions is a new way for the Dokku community to interact with each ot
### The Slack Channel
- [Gliderlabs Slack](https://glider-slackin.herokuapp.com/) (Join the `#dokku` channel)
- [Gliderlabs Slack](https://slack.dokku.com/) (Join the `#dokku` channel)
If you’re stumped, give us a holler in the Dokku Slack channel. Someone from the development team is usually there, especially during the daylight hours for North and South American users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate your brand new sports car.
If you’re stumped, give us a holler in the Dokku Slack channel. Someone from the development team is usually there, especially during the daylight hours for North and South American users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate our brand new sports car.
Chat is synced to Discord and IRC.
### Discord
- [Dokku Discord](https://discord.gg/YQjANGMZvu)
We provide a Dokku Discord that folks can use to ask questions or comments about the project. Someone from the development team is usually there, especially during the daylight hours for North and South American users. Feel free to join us online!
Chat is synced to IRC and Slack.
## Unmonitored Locations
@@ -38,4 +48,4 @@ Tag your questions with `dokku` to enable existing users of Stack Overflow to fi
@@ -65,7 +65,7 @@ If everything is working correctly, you should also be able to query for any oth
If they all return your IP address, you have set DNS up properly for dokku. You should also be able to `ssh root@myserver.example.tld` and access your server.
Proceed with the setup instructions in the [installation documentation](/docs/getting-started/installation.md)
Proceed with the setup instructions in the [installation documentation](/docs/getting-started/installation/index.md)
### Using the root of your domain (node-js-app.example.tld)
@@ -74,4 +74,4 @@ This section is a work in progress. It is incomplete.
Using the 'root' of your domain is nearly identical to the previous example.
* hostname is under `example.tld`, still needs `A` record.
* Update your global domain using the [domains plugin](docs/configuration/domains.md).
* Update your global domain using the [domains plugin](/docs/configuration/domains.md).
@@ -161,7 +161,7 @@ Only a single `$IP:$PORT` combination can be routed to for a given app, and that
> New as of 0.20.0, Requires Docker 1.21+
Apps will default to being associated with the default `bridge` network or a network specified by the `initial-network` network property. Additionally, an app can be attached to `attachable` networks by changing the `attach-post-create` or `attach-post-deploy` network properties when using the [docker-local scheduler](/docs/advanced-usage/schedulers/docker-local.md). A change in these values will require an app deploy or rebuild.
Apps will default to being associated with the default `bridge` network or a network specified by the `initial-network` network property. Additionally, an app can be attached to `attachable` networks by changing the `attach-post-create` or `attach-post-deploy` network properties when using the [docker-local scheduler](/docs/deployment/schedulers/docker-local.md). A change in these values will require an app deploy or rebuild.
```shell
# associates the network after a container is created but before it is started
@@ -308,7 +308,7 @@ dokku network:rebuildall
### Container network interface binding
> This functionality does not control the `--network` docker flag. Please use the [docker-options plugin](docs/advanced-usage/docker-options.md) to manage this flag.
> This functionality does not control the `--network` docker flag. Please use the [docker-options plugin](/docs/advanced-usage/docker-options.md) to manage this flag.
By default, an app will only bind to the internal interface. This behavior can be modified per app by changing the `bind-all-interfaces` network property.
@@ -15,6 +15,8 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
## Usage
> Warning: Mapping alternative ports may conflict with the active firewall installed on your server or hosting provider. Such software includes - but is not limited to - AWS Security Groups, iptables, and UFW. Please consult the documentation for those softwares as applicable.
>
> Users should also avoid setting the `PORT` environment variable. Dokku will use port mappings to set this value. Overriding this manually may cause issues in application routing.
Dokku provides integration with the [Caddy](https://caddyserver.com/) proxy service by utilizing the Docker label-based integration implemented by Caddy.
```
caddy:report [<app>] [<flag>] # Displays a caddy report for one or more apps
Using the `caddy` plugin integration requires the `docker-compose-plugin` for Docker. See [this document](https://docs.docker.com/compose/install/) from the Docker documentation for more information on the installation process for the `docker-compose-plugin`.
## Usage
> Warning: As using multiple proxy plugins on a single Dokku installation can lead to issues routing requests to apps, doing so should be avoided. As the default proxy implementation is nginx, users are encouraged to stop the nginx service before switching to Caddy.
The Caddy plugin has specific rules for routing requests:
- Caddy integration is exposed via docker labels attached to containers. Changes in labels require either app deploys or rebuilds.
- While Caddy will respect labels associated with other containers, only `web` containers have Caddy labels injected by the plugin.
- Only `http:80` and `https:443` port mappings are supported.
- Caddy will automatically enable SSL if the letsencrypt email property is set. SSL will be disabled otherwise.
- If no `http:80` mapping is found, the first `http` port mapping is used for http requests.
- If no `https:443` mapping is found, the first `https` port mapping is used for https requests.
- If no `https` mapping is found, the container port from `http:80` will be used for https requests.
- Requests are routed as soon as the container is running and passing healthchecks.
### Switching to Caddy
To use the Caddy plugin, use the `proxy:set` command for the app in question:
```shell
dokku proxy:set node-js-app caddy
```
This will enable the docker label-based Caddy integration. All future deploys will inject the correct labels for Caddy to read and route requests to containers. Due to the docker label-based integration used by Caddy, a single deploy or rebuild will be required before requests will route successfully.
```shell
dokku ps:rebuild node-js-app
```
Any changes to domains or port mappings will also require either a deploy or rebuild.
### Starting Caddy container
Caddy can be started via the `caddy:start` command. This will start a Caddy container via the `docker compose up` command.
```shell
dokku caddy:start
```
### Stopping the Caddy container
Caddy may be stopped via the `caddy:stop` command.
```shell
dokku caddy:stop
```
The Caddy container will be stopped and removed from the system. If the container is not running, this command will do nothing.
### Showing the Caddy compose config
For debugging purposes, it may be useful to show the Caddy compose config. This can be achieved via the `caddy:show-config` command.
```shell
dokku caddy:show-config
```
### Customizing the Caddy container image
While the default Caddy image is hardcoded, users may specify an alternative by setting the `image` property with the `--global` flag:
It may be necessary to check the Caddy container's logs to ensure that Caddy is operating as expected. This can be performed with the `caddy:logs` command.
```shell
dokku caddy:logs
```
This command also supports the following modifiers:
```shell
--num NUM # the number of lines to display
--tail # continually stream logs
```
You can use these modifiers as follows:
```shell
dokku caddy:logs --tail --num 10
```
The above command will show logs continually from the vector container, with an initial history of 10 log lines
### Changing the Caddy log level
Caddy log output is set to `ERROR` by default. It may be changed by setting the `log-level` property with the `--global` flag:
```shell
dokku caddy:set --global log-level DEBUG
```
After modifying, the Caddy container will need to be restarted.
### SSL Configuration
The caddy plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
#### Enabling letsencrypt integration
By default, letsencrypt is disabled and https port mappings are ignored. To enable, set the `letsencrypt-email` property with the `--global` flag:
After enabling, the Caddy container will need to be restarted and apps will need to be rebuilt. All http requests will then be redirected to https.
#### Customizing the letsencrypt server
The letsencrypt integration is set to the production letsencrypt server by default. To change this, set the `letsencrypt-server` property with the `--global` flag:
After enabling, the Caddy container will need to be restarted and apps will need to be rebuilt to retrieve certificates from the new server.
### Using Caddy's Internal TLS server
To switch to Caddy's internal TLS server for certificate provisioning, set the `tls-internal` property. This can only be set on a per-app basis.
```shell
dokku caddy:set node-js-app tls-internal true
```
## Displaying Caddy reports for an app
You can get a report about the app's Caddy config using the `caddy:report` command:
```shell
dokku caddy:report
```
```
=====> node-js-app caddy information
Caddy image: lucaslorentz/caddy-docker-proxy:2.7
Caddy letsencrypt email:
Caddy letsencrypt server:
Caddy log level: ERROR
Caddy polling interval: 5s
Caddy tls internal: false
=====> python-app caddy information
Caddy image: lucaslorentz/caddy-docker-proxy:2.7
Caddy letsencrypt email:
Caddy letsencrypt server:
Caddy log level: ERROR
Caddy polling interval: 5s
Caddy tls internal: false
=====> ruby-app caddy information
Caddy image: lucaslorentz/caddy-docker-proxy:2.7
Caddy letsencrypt email:
Caddy letsencrypt server:
Caddy log level: ERROR
Caddy polling interval: 5s
Caddy tls internal: false
```
You can run the command for a specific app also.
```shell
dokku caddy:report node-js-app
```
```
=====> node-js-app caddy information
Caddy image: lucaslorentz/caddy-docker-proxy:2.7
Caddy letsencrypt email:
Caddy letsencrypt server:
Caddy log level: ERROR
Caddy polling interval: 5s
Caddy tls internal: false
```
You can pass flags which will output only the value of the specific information you want. For example:
```shell
dokku caddy:report node-js-app --caddy-image
```
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.
