# History
## 0.35.14
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.14/bootstrap.sh
sudo DOKKU_TAG=v0.35.14 bash bootstrap.sh
```
### Bug Fixes
- #7441: @turicas Fix Vagrantfile NFS config
- #7417: @josegonzalez Write contents to stdout before writing to a file
- #7416: @josegonzalez Add missing DOKKU_LIB_HOST_ROOT to ensure plugins work in devcontainer setup
- #7412: @josegonzalez Remove cgroups dependencies
### New Features
- #7439: @josegonzalez Allow specifying a custom app label alias when shipping logs via vector
- #7419: @josegonzalez Add the ability to set a MAILFROM value for local cron emails
### Refactors
- #7415: @josegonzalez Use the golang version of CopyFromImage when copying files in bash
### Documentation
- #7437: @turicas Fix doc generation
- #7414: @josegonzalez Remove copyright date range
### Dependencies
- #7453: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.13 to 10.14 in /docs/_build
- #7451: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.31.0 to 0.32.0 in /plugins/common
- #7449: @dependabot[bot] chore(deps): bump pygments from 2.19.0 to 2.19.1 in /docs/_build
- #7450: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.1 to 1.36.2 in /tests/apps/gogrpc
- #7452: @dependabot[bot] chore(deps): bump traefik from 3.2.3 to 3.3.0 in /plugins/traefik-vhosts
- #7446: @dependabot[bot] chore(deps): bump github.com/otiai10/copy from 1.14.0 to 1.14.1 in /plugins/common
- #7445: @dependabot[bot] chore(deps): bump pygments from 2.18.0 to 2.19.0 in /docs/_build
- #7444: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 45.0.5 to 45.0.6
- #7436: @dependabot[bot] chore(deps): bump pyparsing from 3.2.0 to 3.2.1 in /docs/_build
- #7433: @dependabot[bot] chore(deps): bump k8s.io/kubernetes from 1.29.1 to 1.29.7 in /plugins/scheduler-k3s
- #7429: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.36.1 to 1.36.2 in /plugins/common
- #7427: @dependabot[bot] chore(deps): bump click from 8.1.7 to 8.1.8 in /docs/_build
- #7425: @dependabot[bot] chore(deps): bump jinja2 from 3.1.4 to 3.1.5 in /tests/apps/python-flask
- #7426: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.0 to 1.36.1 in /tests/apps/gogrpc
- #7428: @dependabot[bot] chore(deps): bump jinja2 from 3.1.4 to 3.1.5 in /docs/_build
- #7430: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.12 to 10.13 in /docs/_build
- #7432: @dependabot[bot] chore(deps): bump ruby from 3.3.6 to 3.4.1 in /tests/apps/dockerfile-entrypoint
- #7424: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.69.0 to 1.69.2 in /tests/apps/gogrpc
- #7420: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.35.2 to 1.36.0 in /tests/apps/gogrpc
- #7421: @dependabot[bot] chore(deps): bump traefik from 3.2.2 to 3.2.3 in /plugins/traefik-vhosts
- #7418: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.48 to 9.5.49 in /docs/_build
- #7411: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.68.1 to 1.69.0 in /tests/apps/gogrpc
### Other
- #7434: @turicas Add missing checks:set to checks help
- #7422: @Tashows Fix detached tty for k3s
Rather than writing directly to the file - thus utilizing whatever user docker is being executed as - we copy the file to stdout and then write it to the temp file. This ensures permissions on the file are as expected from Dokku's end.
Closes#7336
# History
## 0.35.13
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.13/bootstrap.sh
sudo DOKKU_TAG=v0.35.13 bash bootstrap.sh
```
### Bug Fixes
- #7410: @josegonzalez Only raise nil responses for k8s list calls as errors
- #7403: @Tashows Properly resolve imagePullSecrets from app and deploymentID if relevant property does not exist
- #7404: @josegonzalez Correctly handle scale to zero with the Keda http addon
- #7400: @Tashows Check if tty is actually used and support proper output when it's not
### Documentation
- #7395: @josegonzalez Add documentation for all file formats dokku uses
- #7399: @nonZero Add -w 0 to base64 call in config:set docs for safe usage in ssh commands
### Tests
- #7380: @josegonzalez Run unit tests outside of docker by default
### Dependencies
- #7409: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.30.0 to 0.31.0 in /plugins/docker-options
- #7405: @dependabot[bot] chore(deps): bump timberio/vector from 0.42.0-debian to 0.43.1-debian in /plugins/logs
- #7407: @dependabot[bot] chore(deps): bump traefik from 3.2.1 to 3.2.2 in /plugins/traefik-vhosts
- #7402: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.36.0 to 1.36.1 in /plugins/common
- #7390: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.29.0 to 0.30.0 in /plugins/common
- #7397: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 45.0.4 to 45.0.5
- #7398: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.47 to 9.5.48 in /docs/_build
- #7394: @dependabot[bot] chore(deps): bump django from 5.0.9 to 5.0.10 in /tests/apps/dockerfile-release
- #7385: @dependabot[bot] chore(deps): bump golang from 1.23.3 to 1.23.4 in /tests/apps/go-fail-predeploy
- #7386: @dependabot[bot] chore(deps): bump golang from 1.23.3 to 1.23.4 in /tests/apps/zombies-dockerfile-tini
- #7387: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.68.0 to 1.68.1 in /tests/apps/gogrpc
- #7388: @dependabot[bot] chore(deps): bump python from 3.13.0-alpine to 3.13.1-alpine in /docs/_build
- #7389: @dependabot[bot] chore(deps): bump six from 1.16.0 to 1.17.0 in /docs/_build
- #7392: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.9.0 to 0.10.0 in /plugins/scheduler-docker-local
- #7393: @dependabot[bot] chore(deps): bump python from 3.13.0-bookworm to 3.13.1-bookworm in /tests/apps/dockerfile-release
- #7384: @dependabot[bot] chore(deps): bump golang from 1.23.3 to 1.23.4 in /tests/apps/gogrpc
- #7383: @dependabot[bot] chore(deps): bump golang from 1.23.3 to 1.23.4 in /tests/apps/zombies-dockerfile-no-tini
- #7382: @dependabot[bot] chore(deps): bump golang from 1.23.3 to 1.23.4 in /tests/apps/go-fail-postdeploy
There is a bug in the Keda project that caused Keda to incorrectly handle empty trigger lists. If self-managing the ScaledObject when using an HTTPScaledObject, an external-push trigger must be created.
This change additionally updates the chart to fix any potential bugs in usage of keda.
Some files - those maintained by external organizations - have a very light treatment and solely point to the upstream documentation to reduce any issues creating examples/documentation for them that may differ in the future.
Closes#7315
# History
## 0.35.12
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.12/bootstrap.sh
sudo DOKKU_TAG=v0.35.12 bash bootstrap.sh
```
### Bug Fixes
- #7361: @josegonzalez Allow autoscaling config to have zero min replicas
### New Features
- #7379: @josegonzalez Provide ability to customize chart values via `scheduler-k3s:set`
### Documentation
- #7365: @binchengqu Correct some documentation types
### Dependencies
- #7378: @josegonzalez Update go modules
- #7376: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.46 to 9.5.47 in /docs/_build
- #7370: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.35.1 to 1.36.0 in /plugins/common
- #7377: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.9 to 2.11.14 in /plugins/scheduler-k3s
- #7369: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.35.1 to 1.36.0 in /plugins/config
- #7371: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.45 to 9.5.46 in /docs/_build
- #7366: @dependabot[bot] chore(deps): bump traefik from 3.2.0 to 3.2.1 in /plugins/traefik-vhosts
- #7364: @dependabot[bot] chore(deps): bump github.com/cert-manager/cert-manager from 1.13.3 to 1.15.4 in /plugins/scheduler-k3s
- #7363: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.44 to 9.5.45 in /docs/_build
- #7360: @dependabot[bot] chore(deps): bump flask from 3.0.3 to 3.1.0 in /tests/apps/python-flask
- #7358: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.35.1 to 1.35.2 in /tests/apps/gogrpc
- #7359: @dependabot[bot] chore(deps): bump flask from 3.0.3 to 3.1.0 in /tests/apps/multi
Dokku ships with default charts and customizes their helm values. In certain cases, it may be useful to further customize those values to better support specific installations. With this change, it is now possible to set custom values by providing the key in the format `chart.$CHART_NAME.$PROPERTY`. For instance, to increase timeouts for the keda http addon:
```shell
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.tcpConnectTimeout 120s
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.keepAlive 120s
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.responseHeaderTimeout 120s
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.idleConnTimeout 120s
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.tlsHandshakeTimeout 120s
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.expectContinueTimeout 120s
```
To reset a value to its default, simply set the value to an empty string.
```shell
dokku scheduler-k3s:set --global chart.keda-add-ons-http.interceptor.tcpConnectTimeout
```
Once the values are set, users will need to then run `scheduler-k3s:ensure-charts` with either the `--force` flag or specify the `--chart` flag with a list of charts to force apply.
```shell
dokku scheduler-k3s:ensure-charts --force
dokku scheduler-k3s:ensure-charts --chart keda-add-ons-http
```
Note that the existing dokku-provided values cannot be removed, but can be overridden.
# History
## 0.35.11
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.11/bootstrap.sh
sudo DOKKU_TAG=v0.35.11 bash bootstrap.sh
```
### Bug Fixes
- #7353: @indrat Add missing export DOKKU_LIB_HOST_ROOT when running dokku in container
### New Features
- #7355: @josegonzalez Add support for http-based scaling when deploying on the k3s scheduler
### Documentation
- #7349: @josegonzalez Create .well-known/funding-manifest-urls
### Dependencies
- #7345: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.67.1 to 1.68.0 in /tests/apps/gogrpc
- #7350: @dependabot[bot] chore(deps): bump zipp from 3.20.2 to 3.21.0 in /docs/_build
- #7351: @dependabot[bot] chore(deps): bump werkzeug from 3.1.2 to 3.1.3 in /tests/apps/python-flask
- #7347: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.28.0 to 0.29.0 in /plugins/common
- #7348: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.8.0 to 0.9.0 in /plugins/common
- #7344: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 45.0.3 to 45.0.4
- #7343: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.8.0 to 0.9.0 in /plugins/scheduler-docker-local
- #7342: @dependabot[bot] chore(deps): bump packaging from 24.1 to 24.2 in /docs/_build
- #7341: @dependabot[bot] chore(deps): bump golang from 1.23.2 to 1.23.3 in /tests/apps/zombies-dockerfile-tini
- #7340: @dependabot[bot] chore(deps): bump golang from 1.23.2 to 1.23.3 in /tests/apps/gogrpc
- #7339: @dependabot[bot] chore(deps): bump golang from 1.23.2 to 1.23.3 in /tests/apps/go-fail-predeploy
- #7338: @dependabot[bot] chore(deps): bump golang from 1.23.2 to 1.23.3 in /tests/apps/zombies-dockerfile-no-tini
- #7337: @dependabot[bot] chore(deps): bump golang from 1.23.2 to 1.23.3 in /tests/apps/go-fail-postdeploy
- #7335: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.43 to 9.5.44 in /docs/_build
- #7334: @dependabot[bot] chore(deps): bump ruby from 3.3.5 to 3.3.6 in /tests/apps/dockerfile-entrypoint
- #7333: @dependabot[bot] chore(deps): bump werkzeug from 3.1.1 to 3.1.2 in /tests/apps/python-flask
### Other
- #7357: @josegonzalez Run brew cleanup before running brew doctor
# History
## 0.35.10
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.10/bootstrap.sh
sudo DOKKU_TAG=v0.35.10 bash bootstrap.sh
```
### Bug Fixes
- #7324: @josegonzalez Correctly pull the deployment id from an app's helm values when executing dokku run under the k3s scheduler
- #7332: @josegonzalez Drop the pod name from stdout output when creating one-off containers under the k3s scheduler
- #7331: @josegonzalez Output logs for completed containers launched by the k3s scheduler
- #7330: @josegonzalez Disable stdio buffering so log coloring happens normally when fetching logs for k3s-scheduler managed apps
- #7329: @josegonzalez Correctly wait for one-off k3s pods to be ready
- #7328: @josegonzalez Execute one-off commands with DOKKU_APP_SHELL as the initial command under the k3s scheduler
- #7323: @josegonzalez Correct errors in brew doctor output when making a formula release
### Dependencies
- #7327: @dependabot[bot] chore(deps): bump watchdog from 5.0.3 to 6.0.0 in /docs/_build
- #7326: @dependabot[bot] chore(deps): bump werkzeug from 3.1.0 to 3.1.1 in /tests/apps/python-flask
Previously, a container that exited immediately would just show an error message, which is probably not what we want.
If the pod has exited, we will display the logs on stdout for the user and then exit appropriately.
This change also refactors how log streaming works so that we respect exiting when the stream has no content (such as when the container has exited). Previously, the container would just hang around forever due to not being properly canceled. Due to this refactor, the prefix is now split out into a separate writer.
This commit changes the launched pod to use the configured DOKKU_APP_SHELL - default /bin/bash - to launch processes. Without this, if a non-interactive process was executed and did not immediately exit, it was possible for that process to launch twice - once when the pod started, and once when entering the pod. Ideally we know whether the process is interactive or not, but this isn't always possible when running under a tty (non-tty == non-interactive). As such, this also removes the ability to launch one-off containers that do not have a configured shell in the container, but this is better than attempting to run commands twice.
The default homebrew setup with the macos-latest runners has issues that cause `brew doctor` to exit non-zero. The exit codes of the commands are ignored in case they are no longer necessary in the future.
# History
## 0.35.9
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.9/bootstrap.sh
sudo DOKKU_TAG=v0.35.9 bash bootstrap.sh
```
### Bug Fixes
- #7321: @josegonzalez Allow nginx commands when the scheduler is set to null
- #7313: @Tashows Remove prefixing releaseName with 'dokku-' in UninstallChart and GetValues calls in scheduler-k3s/triggers.go
### New Features
- #7322: @josegonzalez Add debugging information to brew bump-formula-pr
### Documentation
- #7312: @toanalien Fix typo in nginx documentation
### Dependencies
- #7320: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.34.2 to 1.35.1 in /plugins/common
- #7311: @dependabot[bot] chore(deps): bump traefik from 3.1.6 to 3.2.0 in /plugins/traefik-vhosts
- #7300: @dependabot[bot] chore(deps): bump github.com/fatih/color from 1.17.0 to 1.18.0 in /plugins/common
- #7319: @dependabot[bot] chore(deps): bump werkzeug from 3.0.6 to 3.1.0 in /tests/apps/python-flask
- #7317: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.42 to 9.5.43 in /docs/_build
- #7310: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.11.2 to 10.12 in /docs/_build
- #7299: @dependabot[bot] chore(deps): bump timberio/vector from 0.41.1-debian to 0.42.0-debian in /plugins/logs
- #7306: @dependabot[bot] chore(deps): bump org.apache.maven.plugins:maven-dependency-plugin from 3.8.0 to 3.8.1 in /tests/apps/java
- #7305: @dependabot[bot] chore(deps): bump werkzeug from 3.0.4 to 3.0.6 in /tests/apps/python-flask
# History
## 0.35.8
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.8/bootstrap.sh
sudo DOKKU_TAG=v0.35.8 bash bootstrap.sh
```
### Bug Fixes
- #7295: @josegonzalez Respect the exit code and pass flags correctly when tailing nginx logs on k3s
- #7294: @josegonzalez Tail the correct container in the ingress-nginx pod
- #7293: @josegonzalez Strip non-numeric characters from certain ingress-nginx annotation values
### New Features
- #7296: @josegonzalez Implement nginx:show-config for k3s plugin
### Documentation
- #7297: @josegonzalez Document a required ps:restart in order to apply annotations, labels, and nginx properties
### Dependencies
- #7287: @dependabot[bot] chore(deps): bump mvdan.cc/sh/v3 from 3.9.0 to 3.10.0 in /plugins/cron
- #7288: @dependabot[bot] chore(deps): bump markupsafe from 3.0.1 to 3.0.2 in /docs/_build
- #7289: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.41 to 9.5.42 in /docs/_build
# History
## 0.35.7
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.7/bootstrap.sh
sudo DOKKU_TAG=v0.35.7 bash bootstrap.sh
```
### Bug Fixes
- #7286: @josegonzalez Install netcat-traditional in 24.04 image
- #7284: @josegonzalez Use correct name for scheduler-proxy-logs trigger
- #7285: @josegonzalez Ensure builder pruning works when running under docker
- #7283: @danieldiekmeier Force `docker builder prune` to skip confirmation
# History
## 0.35.6
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.6/bootstrap.sh
sudo DOKKU_TAG=v0.35.6 bash bootstrap.sh
```
### Bug Fixes
- #7279: @josegonzalez Allow exit code 2 when waiting for cloud-init to complete
- #7255: @josegonzalez Do not attempt to expose the same mapped port more than once
### New Features
- #7278: @josegonzalez Allow usage of newer nginx.conf.sigil on older versions of dokku
- #7271: @josegonzalez Add support for non-local nginx implementations
- #7269: @josegonzalez Add support for various timeout-related functions to nginx, openresty and k3s plugins
### Dependencies
- #7272: @dependabot[bot] chore(deps): bump node from 22-alpine to 23-alpine in /tests/apps/dockerfile
- #7273: @dependabot[bot] chore(deps): bump node from 22-alpine to 23-alpine in /tests/apps/dockerfile-procfile
- #7274: @dependabot[bot] chore(deps): bump node from 22-alpine to 23-alpine in /tests/apps/dockerfile-app-json-formations
- #7275: @dependabot[bot] chore(deps): bump node from 22-alpine to 23-alpine in /tests/apps/dockerfile-noexpose
- #7276: @dependabot[bot] chore(deps): bump node from 22-alpine to 23-alpine in /tests/apps/dockerfile-procfile-bad
- #7270: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.40 to 9.5.41 in /docs/_build
- #7264: @dependabot[bot] chore(deps): bump pyparsing from 3.1.4 to 3.2.0 in /docs/_build
- #7244: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.27.0 to 0.28.0 in /plugins/common
- #7260: @dependabot[bot] chore(deps): bump traefik from 3.1.5 to 3.1.6 in /plugins/traefik-vhosts
- #7259: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.39 to 9.5.40 in /docs/_build
- #7258: @dependabot[bot] chore(deps): bump markupsafe from 3.0.0 to 3.0.1 in /docs/_build
- #7254: @dependabot[bot] chore(deps): bump cookie and express in /tests/apps/checks-root
- #7246: @dependabot[bot] chore(deps): bump python from 3.12.7-alpine to 3.13.0-alpine in /docs/_build
- #7247: @dependabot[bot] chore(deps): bump python from 3.12.7-bookworm to 3.13.0-bookworm in /tests/apps/dockerfile-release
- #7248: @dependabot[bot] chore(deps): bump markupsafe from 2.1.5 to 3.0.0 in /docs/_build
- #7252: @dependabot[bot] chore(deps): bump django from 5.0.8 to 5.0.9 in /tests/apps/dockerfile-release
### Other
- #7282: @josegonzalez Skip ssh key setup when starting docker image
- #7281: @josegonzalez Set hostname to dokku.me for devcontainer
- #7280: @josegonzalez Merge changes from digitialocean's image-check script
When deploying the Dokku via Docker, ssh keys are added directly via the ssh-keys:add command, and thus we can skip this step completely (as there won't be a public key in that path).
A change in cloud-init and/or the Ubuntu image provided by Digitalocean causes builds to fail due to cloud-init status exiting 2. The error is ignorable.
See digitalocean/marketplace-partners#186 for more details.
Folks might mistakenly pull the latest template file - which introduces new variables - causing deployment failures.
This change allows them to use the newer template by checking if the variables are set before using them.
Closes#7277
If the scheduler is not docker-local, we will assume that a separate plugin trigger will pull access/error logs on our behalf. For k3s, the naive implementation is to pull logs from a single container (multiple ingress-nginx pods will be supported in a future release).
Closes#7268
A newer release of Docker (27.3.1) appears to have issues with the -p flag appearing the same time more than once for a given port. This was previously not an issue, but we should remove the problem on our end regardless.
Closes#7251
# History
## 0.35.5
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.5/bootstrap.sh
sudo DOKKU_TAG=v0.35.5 bash bootstrap.sh
```
### New Features
- #7213: @josegonzalez Release Dokku on supported versions of Debian and Raspbian
### Documentation
- #7241: @josegonzalez Clarify phase utilization in docker-options docs
- #7240: @josegonzalez Update testing docs to specify that CI is performed on Ubuntu Noble
- #7218: @josegonzalez Fix reference to arm64
- #7215: @Lewiscowles1986 Clarify x64 as amd64/arch64 in readme
### Tests
- #7212: @josegonzalez Update python version used in test apps
### Dependencies
- #7243: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.34.2 to 1.35.1 in /tests/apps/gogrpc
- #7238: @dependabot[bot] chore(deps): bump tj-actions/changed-files from 45.0.2 to 45.0.3
- #7237: @dependabot[bot] chore(deps): bump traefik from 3.1.4 to 3.1.5 in /plugins/traefik-vhosts
- #7227: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.67.0 to 1.67.1 in /tests/apps/gogrpc
- #7231: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.11.1 to 10.11.2 in /docs/_build
- #7228: @dependabot[bot] chore(deps): bump golang from 1.23.1 to 1.23.2 in /tests/apps/go-fail-postdeploy
- #7229: @dependabot[bot] chore(deps): bump golang from 1.23.1 to 1.23.2 in /tests/apps/zombies-dockerfile-tini
- #7230: @dependabot[bot] chore(deps): bump python from 3.12.6-bookworm to 3.12.7-bookworm in /tests/apps/dockerfile-release
- #7232: @dependabot[bot] chore(deps): bump golang from 1.23.1 to 1.23.2 in /tests/apps/go-fail-predeploy
- #7233: @dependabot[bot] chore(deps): bump python from 3.12.6-alpine to 3.12.7-alpine in /docs/_build
- #7234: @dependabot[bot] chore(deps): bump golang from 1.23.1 to 1.23.2 in /tests/apps/zombies-dockerfile-no-tini
- #7235: @dependabot[bot] chore(deps): bump golang from 1.23.1 to 1.23.2 in /tests/apps/gogrpc
- #7220: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.38 to 9.5.39 in /docs/_build
- #7221: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.10.2 to 10.11.1 in /docs/_build
- #7222: @dependabot[bot] chore(deps): bump watchdog from 5.0.2 to 5.0.3 in /docs/_build
### Other
- #7245: @moenoel fix: #7035 broke traefik https router rule
So I started by searching after reading README.md, and came across #6312
Maybe others assume x64 is synonymous with 64-bit, but I find the long-hand, helped me to understand that arm64 and aarch64, and amd64 as well as x86_64 (which I thought x64 most closely resembled) are all supported, and it's a minimum native bus width limitation, dispensing with the history of x86 and 8086, than anything else.
The policy has always been to only release for supported versions of operating systems, so this change aligns what we release for and how Dokku may be installed.
Folks running unmaintained operating systems should upgrade, as the packages are never guaranteed to exist in the Dokku apt repository.
# History
## 0.35.4
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.4/bootstrap.sh
sudo DOKKU_TAG=v0.35.4 bash bootstrap.sh
```
### Bug Fixes
- #7209: @josegonzalez Exit non-zero if any deployment tasks fails
- #7211: @josegonzalez Always set the git rev env var when building an app via git:sync
- #7208: @josegonzalez Compute path for docker-container-healthchecker
- #7205: @Cactusbone chore: fix vagrant dokku-windows config
### Tests
- #7210: @josegonzalez Ensure pack binary is installed correctly when running tests in a devcontainer
### Dependencies
- #7206: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.37 to 9.5.38 in /docs/_build
- #7207: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.10.1 to 10.10.2 in /docs/_build
- #7203: @dependabot[bot] chore(deps): bump mkdocs-material from 9.5.36 to 9.5.37 in /docs/_build
This fixes an issue for source-based Dokku installs where the binary is installed in /usr/local/bin instead of /usr/bin due to not being installed via an OS package.
Closes#7010
# History
## 0.35.3
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.3/bootstrap.sh
sudo DOKKU_TAG=v0.35.3 bash bootstrap.sh
```
### Bug Fixes
- #7200: @josegonzalez Automatically select a container type if none is specified
- #7199: @josegonzalez Check if nginx is running before reloading during an app deletion
- #7198: @josegonzalez Add builder-herokuish to default help output
- #7197: @josegonzalez Implement missing network:info command
### Tests
- #7201: @josegonzalez Run arm build on 22.04
### Dependencies
- #7193: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.9 to 10.10.1 in /docs/_build
- #7194: @dependabot[bot] chore(deps): bump traefik from 3.1.2 to 3.1.4 in /plugins/traefik-vhosts
- #7195: @dependabot[bot] chore(deps): bump dokku/openresty-docker-proxy from 0.9.0 to 0.9.1 in /plugins/openresty-vhosts
- #7196: @dependabot[bot] chore(deps): bump socket.io from 4.7.5 to 4.8.0 in /tests/apps/.websocket.disabled
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.
The `docker-options` plugin allows users to specify custom [container options](https://docs.docker.com/engine/reference/run/) for containers created by Dokku at various phases.
## About Dokku phases
## Usage
Dokku deploys your application in multiple "phases" and the `docker-options` plugin allows you to pass arguments to their underlying docker container:
### Background
-`build`: the container that executes the appropriate buildpack
-`deploy`: the container that executes your running/deployed application
-`run`: the container that executes any arbitrary command via `dokku run`
#### Phases
Manipulation of docker options will not restart running containers. This enables multiple options to be set/unset before final application. As such, changing an app's dockeroptions must be followed by a `dokku ps:rebuild` in order to take effect.
Dokku deploys your app in multiple "phases" and the `docker-options` plugin allows you to pass arguments to their underlying docker container:
-`build`: The `build` phase is used to provide container options that are available during the build process for use by the various builders.
- A given builder may strip out or ignore options that are unsupported by the builder in question - as an example, the `dockerfile` builder does not support mounted volumes.
-`deploy`: The `deploy` phase is used to provide container options that are set on _deployed_ process types. This covers every process type specified in an app `Procfile` as well as any default processes your app may deploy.
- The `deploy` phase is usually the correct phase to add options for
-`run`: The `run` phase is used to provide container options to one-off containers created by `dokku run`, `dokku run:detached`, and any cron tasks specified in your `app.json`.
> [!IMPORTANT]
> The `run` phase does _not_ correspond 1-to-1 to `docker run` or `docker container run` commands. Specifying a container option at the `run` phase will only be invoked on containers created by the `run` plugin and cron tasks. Please be sure to specify options at the correct phase for your use-case.
Adding or removing docker-options will not apply to any running containers, and only applies to containers created _after_ the options have been modified. As such, changing an app's docker options must be followed by a `dokku ps:rebuild` or a deploy in order to take effect.
#### Supported Docker Options
More information on supported Docker options can be found [here](https://docs.docker.com/engine/reference/commandline/run/).
Container options configured via the `docker-options` plugin are not used to modify the process a container runs. Container options are the `[OPTIONS]` portion of the following, where `[CONTAINER_COMMAND]` and `[ARG]` are the process and the arguments passed to it that are launched in the created container: `docker run [OPTIONS] [CONTAINER_COMMAND] [ARG...]`. Please see the documentation for [customizing the run command](/docs/deployment/builders/dockerfiles.md#customizing-the-run-command) or use a [Procfile](/docs/deployment/builders/dockerfiles.md#procfiles-and-multiple-processes) to modify the command used by a Dockerfile-based container.
## Examples
#### Mounting volumes and host directories
### Add Docker options
Docker supports volume and host directory mounting via the `-v` or `--volume` flags. In order to simplify usage, Dokku provides a `storage` plugin as an abstraction to interact with persistent storage. In most cases, the Dokku project recommends using the persistent storage plugin over directly manipulating docker options at different phases. See the [persistent storage documentation](/docs/advanced-usage/persistent-storage.md) for more information on how to attach persistent storage to your app.
Add some options for the deployed/running app and when executing [`dokku run`](/docs/processes/one-off-tasks.md):
### Commands
#### Add Docker options
To add a docker option to an app, use the `docker-options:add` command. This takes an app name, a comma-separated list of phases, and the docker-option to add.
```shell
# Mount a host volume in a Docker container: "-v /host/path:/container/path"
> When [mounting a host directory](https://docs.docker.com/engine/reference/run/#volume-shared-filesystems) in a Dokku app you should first create that directory as user `dokku` and then mount the directory under `/app` in the container using `docker-options` as above. Otherwise the app will lack write permission in the directory.
### Remove a Docker option
Multiple phases can be specified by using a comma when specifying phases:
```shell
dokku docker-options:remove node-js-app run "-v /var/log/node-js-app:/app/logs"
The `docker-options:add` does not support setting multiple options in a single call. To specify multiple options, call `docker-options:add` multiple times.
To remove docker options from an app, use the `docker-options:remove` command. This takes an app name, a comma-separated list of phases, and the docker-option to remove.
```shell
dokku docker-options:remove node-js-app run ""--ulimit nofile=12"
```
Multiple phases can be specified by using a comma when specifying phases:
The `docker-options:remove` does not support setting multiple options in a single call. To specify multiple options, call `docker-options:remove` multiple times.
`app.json` is a manifest format for describing web apps. It declares cron tasks, healthchecks, and other information required to run an app on Dokku. This document describes the schema in detail.
> [!IMPORTANT]
> While the `app.json` format used by Dokku is based on the one [supported by Heroku](https://devcenter.heroku.com/articles/app-json-schema), not all Heroku functionality is supported by Dokku.
## Cron
```json
{
"crons":[
{
"command":"echo 'hello'",
"schedule":"0 1 * * *"
}
]
}
```
(list, optional) A list of cron resources. Keys are the names of the process types. The values are an object containing one or more of the following properties:
-`command`: (string, required)
-`schedule`: (string, required)
## Formation
```json
{
"formation":{
"web":{
"max_parallel":1,
"quantity":1
}
}
}
```
(object, optional) A key-value object for process type configuration. Keys are the names of the process types. The values are an object containing one or more of the following properties:
-`autoscaling` (map of string to object, optional) autoscaling rules. See the autoscaling section for more details
-`max_parallel`: (int, optional) number of instances to deploy in parallel at a given time
-`quantity`: (int, optional) number of processes to maintain. Default 1 for web processes, 0 for all others.
### Autoscaling
```json
{
"formation":{
"web":{
"autoscaling":{
"cooldown_period_seconds":300,
"max_quantity":10,
"min_quantity":1,
"polling_interval_seconds":30,
"triggers":{
"http":{
"metadata":{
"url":"https://example.com/health"
}
}
}
}
}
}
}
```
(object, optional) A key-value object for autoscaling configuration. Keys are the names of the process types. The values are an object containing one or more of the following properties:
-`cooldown_period_seconds`: (int, optional)
-`max_quantity`: (int, optional)
-`min_quantity`: (int, optional)
-`polling_interval_seconds`: (int, optional)
-`triggers`: (object, optional)
An autoscaling trigger consists of the following properties:
-`name`: (string, optional)
-`type`: (string, optional)
-`metadata`: (object, optional)
## Healthchecks
```json
{
"healthchecks":{
"web":[
{
"type":"startup",
"name":"web check",
"description":"Checking if the app responds to the /health/ready endpoint",
"path":"/health/ready",
"attempts":3
}
]
}
}
```
(object, optional) A key-value object specifying healthchecks to run for a given process type.
-`attempts`: (int, optional)
-`command`: (list of strings, optional)
-`content`: (string, optional)
-`httpHeaders`: (list of header objects, optional)
When installed, a buildpack is checked to see if it is a git repository via `git ls-remote`. If it is not, the buildpack is checked to see if it ends in `.tgz`, `.tar.gz`, `.tbz`, `tar.bz`, or `.tar` and is downloaded/extracted before being executed.
If the buildpack is located on Github, a shorthand can be used in the form of `organization/buildpack-name`. This will be expanded to the `https://github.com/organization/heroku-buildpack-buildpack-name.git`. The `heroku-community` organization name is treated as `heroku`.
Comments are not allowed in the `.buildpacks` file.
A Dockerfile is used to build a Docker image for an application. Please refer to the [Dockerfile reference](https://docs.docker.com/reference/dockerfile/) for more information.
`build_image`: A docker image that is accessible by the docker daemon. The `build_image` should be based on an existing Lambda image - builders may fail if they cannot run within the specified `build_image`. The build will fail if the image is inaccessible by the docker daemon.
`builder`: The name of a builder. This may be used if multiple builders match and a specific builder is desired. If an invalid builder is specified, the build will fail.
`run_image`: A docker image that is accessible by the docker daemon. The `run_image` should be based on an existing Lambda image - built images may fail to start if they are not compatible with the produced artifact. The generation of the `run_image` will fail if the image is inaccessible by the docker daemon.
The `nginx.conf.sigil` file is used to configure the nginx server for an application. The default template can be found [here](https://github.com/dokku/dokku/blob/master/plugins/nginx-vhosts/templates/nginx.conf.sigil). Dokku uses a tool named [sigil](https://github.com/gliderlabs/sigil) to generate the nginx configuration based on the template provided.
The `nixpacks.toml` file is used to configure an application when built with the `nixpacks` builder. Please refer to the [nixpacks.toml documentation](https://nixpacks.com/docs/configuration/file.md) for more information.
A Procfile is a file that was [promoted by Heroku](https://blog.heroku.com/the_new_heroku_1_process_model_procfile) for their platform as an easy way to specify one or more distinct processes to run within Heroku. This format has since been picked up by various other tools and platforms.
## General Overview
The `procfile-util` tool expects a Procfile to be defined as one or more lines containing one of:
- a comment (preceeded by a `#` symbol or two `//` characters)
- a process-type/command combination (with optional trailing whitespace or trailing comment)
- when there is a trailing comment, the `#` symbol/`//` characters _must_ be preceeded by one or more `whitespace` characters.
- a blank line (with optional trailing whitespace)
Comments and blank lines are ignored, while process-type/command combinations look like the following:
```
<process type>: <command>
```
The syntax is defined as follows:
-`<process type>`– any character in the class `[A-Za-z0-9_-]+`, a process type is a name for your command, such as `web`, `worker`, `urgentworker`, `clock`, etc.
-`<command>`– a command used to launch the process, such as `rake jobs:work`
Additional rules are as follows:
- contain at most 63 characters
A Procfile that does not match any of the above rules will be considered invalid, and not be processed. This is to avoid issues where a Procfile may contain merge conflicts or other improper content, thus resulting in unwanted runtime behavior for applications.
Finally, process types within a Procfile may not overlap and must be unique. Rather than assuming that the last or first specified is correct, `procfile-util` will fail to parse the Procfile with the relevant error.
### Strict Mode
> Strict mode can be triggered on `procfile-util` via the `--strict` flag.
In strict mode, the character set of a process type changes.
-`<process type>`– a valid DNS Label Name as per [RFC 1123](https://tools.ietf.org/html/rfc1123), a process type is a name for your command, such as `web`, `worker`, `urgentworker`, `clock`, etc.
This syntax differs common interpretations of valid `<process type>` values in that we define the process type as a DNS Label name, versus the regex `[A-Za-z0-9_]+`. The reason for this is that processes defined within Procfiles are commonly used in DNS entries. Rather than have a second level of platform-specific validation in place, this project implicitly defines the format for the process-type.
Given the above, a valid process type can be generalized to the following rules (as taken from the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names)):
- contain at most 63 characters
- contain only lowercase alphanumeric characters or '-'
The project descriptor file allows app developers to provide configuration for apps deployed to Dokku via the `pack` builder. Please refer to the [project.toml documentation](https://buildpacks.io/docs/reference/config/project-descriptor/) for more information.
Dokku can also read base64 encoded values. That's the easiest way to set a value with newlines or spaces. To set a value with newlines you need to base64 encode it first and pass the `--encoded` flag:
When setting or unsetting environment variables, you may wish to avoid an application restart. This is useful when developing plugins or when setting multiple environment variables in a scripted manner. To do so, use the `--no-restart` flag:
@@ -233,3 +233,33 @@ dokku logs:set test vector-sink "http://?uri=https%3A//loggerservice.com%3A1234/
```
Please read the [sink documentation](https://vector.dev/docs/reference/configuration/sinks/) for your sink of choice to configure the sink as desired.
##### Configuring the app label
Logs shipped by vector include the label `com.dokku.app-name`, which is an alias for the app name. This can be changed via the `app-label-alias` logs property with the `logs:set` command. Specifying a new alias will reload any running vector container.
```shell
# setting the sink value in quotes is encouraged to avoid
# issues with ampersand encoding in shell commands
scheduler-k3s:cluster-add [ssh://user@host:port] # Adds a server node to a Dokku-managed cluster
scheduler-k3s:cluster-list # Lists all nodes in a Dokku-managed cluster
scheduler-k3s:cluster-remove [node-id] # Removes client node to a Dokku-managed cluster
scheduler-k3s:ensure-charts # Ensures the k3s charts are installed
scheduler-k3s:initialize # Initializes a cluster
scheduler-k3s:labels:set <app|--global> <property> (<value>) [--process-type PROCESS_TYPE] <--resource-type RESOURCE_TYPE>, Set or clear a label for a given app/process-type/resource-type combination
scheduler-k3s:report [<app>] [<flag>] # Displays a scheduler-k3s report for one or more apps
@@ -61,7 +62,7 @@ By default, Dokku will attempt to auto-detect the IP address of the server. In c
Dokku's k3s integration natively uses `nginx` as it's ingress load balancer via [ingress-nginx](https://github.com/kubernetes/ingress-nginx). Properties set by the `nginx` plugin will be respected, either by turning them into annotations or creating a custom server/location snippet that the `ingress-nginx` project can use.
Dokku's k3s integration natively uses `nginx` as it's ingress load balancer via [ingress-nginx](https://github.com/kubernetes/ingress-nginx). Properties set by the `nginx` plugin will be respected, either by turning them into annotations or creating a custom server/location snippet that the `ingress-nginx` project can use. A `ps:restart` is required after changing nginx properties in order to have them apply to running resources.
Dokku can also use Traefik on cluster initialization via the [Traefik's CRDs](https://doc.traefik.io/traefik/providers/kubernetes-crd/). To change the ingress, set the `--ingress-class` flag:
@@ -312,6 +313,8 @@ The following resource types are supported:
-`traefik_ingressroute`
-`traefik_middleware`
A `ps:restart` is required after setting annotations in order to have them apply to running resources.
#### Removing an annotation
To unset an annotation, pass an empty value:
@@ -321,6 +324,8 @@ dokku scheduler-k3s:annotations:set node-js-app annotation.key --resource-type d
dokku scheduler-k3s:annotations:set node-js-app annotation.key --resource-type deployment --process-type web
```
A `ps:restart` is required after removing annotations in order to remove them from running resources.
#### Setting Labels
Dokku injects certain labels into each created resource by default, but it may be necessary to inject others for tighter integration with third-party tools. The `scheduler-k3s:labels:set` command can be used to perform this task. The command takes an app name and a required `--resource-type` flag.
@@ -349,6 +354,8 @@ The following resource types are supported:
-`traefik_ingressroute`
-`traefik_middleware`
A `ps:restart` is required after setting labels in order to have them apply to running resources.
dokku scheduler-k3s:labels:set node-js-app label.key --resource-type deployment --process-type web
```
A `ps:restart` is required after removing labels in order to remove them from running resources.
### Autoscaling
#### Workload Autoscaling
@@ -408,6 +417,56 @@ Each value in the `metadata` stanza can use the following interpolated strings:
-`DOKKU_PROCESS_TYPE`: The name of the process being scaled
-`DOKKU_APP_NAME`: The name of the app being scaled
##### HTTP Autoscaling
In addition to the built-in scalers that Keda provides, Dokku also supports Keda's HTTP Add On. This requires that the addon be properly installed and configured. For existing k3s clusters, this can be performed by the `scheduler-k3s:ensure-charts` command:
```shell
dokku scheduler-k3s:ensure-charts
```
> [!NOTE]
> Users who wish to use this functionality on a cluster not managed by Dokku will need to manually install the `keda-http-add-on` into the `keda` namespace. Please consult the `keda-http-add-on` [install documentation](https://kedacore.github.io/http-add-on/install.html) for further details.
> [!WARNING]
> If the `keda-http-add-on` chart is not installed, then this trigger will be ignored.
Once the chart is configured, an `http` trigger can be specified like so:
```json
{
"formation":{
"web":{
"autoscaling":{
"min_quantity":1,
"max_quantity":10,
"triggers":[
{
"type":"http",
"metadata":{
"scaledown_period_seconds":"150",
"request_rate_target_value":"50"
}
}
]
}
}
}
}
```
The following metadata properties are supported with the http autoscaler:
-`scale_by`: (default: `request_rate`) whether to scale by `concurrency` or `request_rate`.
-`scaledown_period_seconds`: (default: `300`) period to wait after the last reported active before scaling the resource back to 0.
-`request_rate_granularity_seconds`: (default: `1`) granualarity of the aggregated requests for the request rate calculation.
-`request_rate_target_value`: (default: `100`) target value for the request rate.
-`request_rate_window_seconds`: (default: `60`) aggregation window for the request rate calculation.
-`concurrency_target_value`: (default: `100`) target value for the request concurrency.
Note that due to Keda limitations, scaling is done by _either_`concurrency` or `request_rate`.
#### Workload Autoscaling Authentication
Most Keda triggers require some form of authentication to query for data. In the Kubernetes API, they are represented by `TriggerAuthentication` and `ClusterTriggerAuthentication` resources. Dokku can manage these via the `scheduler-k3s:autoscaling-auth` commands, and includes generated resources with each helm release generated by a deploy.
The default value for the `kube-context` is an empty string, and will result in Dokku using the current context within the kubeconfig.
### Customizing Helm Chart Properties
Dokku includes a number of helm charts by default with settings that are optimized for Dokku. That said, it may be useful to further customize the charts for a given environment. Users can customize which charts are installed by setting properties prefixed with `chart.$CHART_NAME.` with the `--global` flag.
> Properties follow dot-notation, and are expanded according to Helm's internal logic. See the [Helm documentation](https://helm.sh/docs/helm/helm_install/#helm-install) for `helm install` for further details.
To unset a chart property, omit the value from the `scheduler-k3s:set` call:
A `scheduler-k3s:ensure-charts` command with the `--force` flag is required after changing any chart properties in order to have them apply. This will install all charts, not just the ones that have changed.
```shell
dokku scheduler-k3s:ensure-charts --force
```
Alternatively, a comma separated list of chart names can be specified to only force install the specified charts:
The following sections describe implemented and unimplemented scheduler functionality for the `k3s` scheduler.
@@ -528,13 +617,17 @@ This plugin implements various functionality through `plugn` triggers to integra
-`enter`
-`deploy`
- healthchecks
- Due to Kubernetes limitations, only a single healthcheck is supported for each of the `liveness`, `readiness`, and `startup` healthchecks
- Due to Kubernetes limitations, content checks are not supported
- Ports specified in the `app.json` are ignored in favor of the container port on the port mapping detected
- Due to Kubernetes limitations, only a single healthcheck is supported for each of the `liveness`, `readiness`, and `startup` healthchecks
- Due to Kubernetes limitations, content checks are not supported
- Ports specified in the `app.json` are ignored in favor of the container port on the port mapping detected
-`logs`
-`nginx`
- Properties set by the `nginx` plugin will be respected, either by turning them into annotations or creating a custom server/location snippet that the `ingress-nginx` project can use. A `ps:restart` after changing any nginx properties is required in order to have them apply.
- The `nginx:access-logs` and `nginx:error-logs` commands will fetch logs from one running `ingress-nginx` pod.
- The `nginx:show-config` command will retrieve any `server` blocks associated with a domain attached to the app from one running `ingress-nginx` pod.
-`ps:stop`
-`run`
- The `scheduler-post-run` trigger is not always triggered
- The `scheduler-post-run` trigger is not always triggered
@@ -9,11 +9,11 @@ We maintain the Dokku test harness within the `tests` directory:
## Continuous Integration
All pull requests have tests run against them on [GitHub Actions](https://github.com/features/actions), a continuous integration platform that provides Docker support for Ubuntu Jammy 22.04.
All pull requests have tests run against them on [GitHub Actions](https://github.com/features/actions), a continuous integration platform that provides Docker support for Ubuntu Noble 24.04.
If you wish to skip tests for a particular commit, e.g. documentation changes, you may add the `[ci skip]` designator to your commit message. Commits that _should_ be tested but have the above designator will not be merged.
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Jammy 22.04, we only provide official installation support for that platform and the supported LTS releases of Ubuntu (currently 20.04, 22.04, and 24.04).
While we do provide official packages for a variety of platforms, as our test suite currently runs on Ubuntu Noble 24.04, we only provide official installation support for that platform and the supported LTS releases of Ubuntu (currently 20.04, 22.04, and 24.04).
The alternative is to build a custom docker image via a custom Dockerfile. This Dockerfile can run any `plugin:install` command. Note that the version installed at that time will be the one that persists. Below is an example Dockerfile showing this method.
```Dockerfile
FROMdokku/dokku:0.35.2
FROMdokku/dokku:0.35.14
RUN dokku plugin:install https://github.com/dokku/dokku-postgres.git postgres
RUN dokku plugin:install https://github.com/dokku/dokku-redis.git redis
network:create <network> # Creates an attachable docker network
network:destroy <network> # Destroys a docker network
network:exists <network> # Checks if a docker network exists
network:info <network> # Outputs information about a docker network
network:list # Lists all docker networks
network:report [<app>] [<flag>] # Displays a network report for one or more apps
network:rebuild <app> # Rebuilds network settings for an app
network:rebuildall # Rebuild network settings for all apps
network:set <app> <key> (<value>) # Set or clear a network property for an app
network:create <network> # Creates an attachable docker network
network:destroy <network> # Destroys a docker network
network:exists <network> # Checks if a docker network exists
network:info <network> [--format text|json] # Outputs information about a docker network
network:list [--format text|json] # Lists all docker networks
network:report [<app>] [<flag>] # Displays a network report for one or more apps
network:rebuild <app> # Rebuilds network settings for an app
network:rebuildall # Rebuild network settings for all apps
network:set <app> <key> (<value>) # Set or clear a network property for an app
```
The Network plugin allows developers to abstract the concept of container network management, allowing developers to both change what networks a given container is attached to as well as rebuild the configuration on the fly.
@@ -51,6 +51,21 @@ none
test-network
```
The `network:list` command also takes a `--format` flag, with the valid options including `text` (default) and `json`. The `json` output format can be used for automation purposes:
@@ -117,16 +132,30 @@ The `network:exists` command will return non-zero if the network does not exist,
### Checking network info
> [!IMPORTANT]
> New as of 0.20.0, Requires Docker 1.21+
> New as of 0.35.3
Network information can be retrieved via the `network:info` command. This is a slightly different version of the `docker network` command.
```shell
dokku network:info test-network
dokku network:info bridge
```
```
// TODO
=====> bridge network information
ID: d18df2d21433
Name: bridge
Driver: bridge
Scope: local
```
The `network:info` command also takes a `--format` flag, with the valid options including `text` (default) and `json`. The `json` output format can be used for automation purposes:
The value is the path to the desired file *relative* to the base search directory, and will never be treated as absolute paths in any context. If that file does not exist within the repository, Dokku will continue the build process as if the repository has no `nginx.conf.sigil`.
The value is the path to the desired file _relative_ to the base search directory, and will never be treated as absolute paths in any context. If that file does not exist within the repository, Dokku will continue the build process as if the repository has no `nginx.conf.sigil`.
The default value may be set by passing an empty value for the option:
@@ -315,28 +315,35 @@ Changing these value globally or on a per-app basis will require rebuilding the
> [!WARNING]
> Validation is not performed against the values, and they are used as is within Dokku.
| access-log-format | empty string | string | Name of custom log format to use (log format must be specified elsewhere) |
| access-log-path | `${NGINX_LOG_ROOT}/${APP}-access.log` | string | Log path for nginx access logs (set to `off` to disable) |
| bind-address-ipv4 | `0.0.0.0` | string | Default IPv4 address to bind to |
| bind-address-ipv6 | `[::]` | string | Default IPv6 address to bind to |
| client-max-body-size | `1m` | string | Size (with units) of client request body (usually modified for file uploads) |
| client-body-timeout | `60s` | string | Timeout (with units) for reading the client request body |
| client-header-timeout | `60s` | string | Timeout (with units) for reading the client request headers |
| error-log-path | `${NGINX_LOG_ROOT}/${APP}-error.log` | string | Log path for nginx error logs (set to `off` to disable) |
| hsts | `true` | boolean | Enables or disables HSTS for your application |
| hsts-include-subdomains | `true` | boolean | Forces the browser to apply the HSTS policy to all app subdomains |
| hsts-max-age | `15724800` | integer | Time in seconds to cache HSTS configuration |
| hsts-preload | `false` | boolean | Tells the browser to include the domain in their HSTS preload lists |
| keepalive-timeout | `75s` | string | Timeout (with units) during which a keep-alive client connection will stay open on the server side |
| lingering-timeout | `5s` | string | Timeout (with units) is the maximum waiting time for more client data to arrive |
| nginx-conf-sigil-path | `nginx.conf.sigil` | string | Path in the repository to the `nginx.conf.sigil` file |
| proxy-buffer-size | `8k` (# is os pagesize) | string | Size of the buffer used for reading the first part of proxied server response |
| proxy-buffering | `on` | string | Enables or disables buffering of responses from the proxied server |
| proxy-buffers | `8 8k` | string | Number and size of the buffers used for reading the proxied server response, for a single connection |
| proxy-busy-buffers-size | `16k` | string | Limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. |
| proxy-connect-timeout | `60s` | string | Timeout (with units) for establishing a connection to your backend server |
| proxy-read-timeout | `60s` | string | Timeout (with units) for reading response from your backend server |
| proxy-send-timeout | `60s` | string | Timeout (with units) for transmitting a request to your backend server |
| send-timeout | `60s` | string | Timeout (with units) for transmitting a response to your the client |
| underscore-in-headers | `off` | string | Enables or disables the use of underscores in client request header fields. |
| x-forwarded-for-value | `$remote_addr` | string | Used for specifying the header value to set for the `X-Forwarded-For` header |
| x-forwarded-port-value | `$server_port` | string | Used for specifying the header value to set for the `X-Forwarded-Port` header |
| x-forwarded-proto-value | `$scheme` | string | Used for specifying the header value to set for the `X-Forwarded-Proto` header |
| x-forwarded-for-value | `$remote_addr` | string | Used for specifying the header value to set for the `X-Forwarded-For` header |
| x-forwarded-port-value | `$server_port` | string | Used for specifying the header value to set for the `X-Forwarded-Port` header |
| x-forwarded-proto-value | `$scheme` | string | Used for specifying the header value to set for the `X-Forwarded-Proto` header |
| x-forwarded-ssl | empty string | string | Less commonly used alternative to `X-Forwarded-Proto` (valid values: `on` or `off`) |
#### Binding to specific addresses
@@ -377,7 +384,6 @@ Properties:
-`x-forwarded-proto-value`
-`x-forwarded-ssl`
Dokku's default Nginx configuration passes the de-facto standard HTTP headers [`X-Forwarded-For`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For), [`X-Forwarded-Proto`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto), and `X-Forwarded-Port` to your application.
These headers indicate the IP address of the original client making the request, the protocol of the original request (HTTP or HTTPS), and the port number of the original request, respectively.
@@ -426,7 +432,7 @@ dokku nginx:set node-js-app error-log-path off
Properties:
-`acccess-log-format`
-`access-log-format`
Prior to changing the log-format, log formats should be specified at a file such as `/etc/nginx/conf.d/00-log-formats.conf`. This will ensure they are available within your app's nginx context. For instance, the following may be added to the above file. It only needs to be specified once to be used for all apps.
@@ -469,7 +475,6 @@ This property is commonly used to increase the max file upload size.
Changing this value when using the PHP buildpack (or any other buildpack that uses an intermediary server) will require changing the value in the server config shipped with that buildpack. Consult your buildpack documentation for further details.
@@ -66,7 +66,7 @@ dokku run --no-tty node-js-app ls -lah
> [!IMPORTANT]
> New as of 0.25.0
Finally, a container can be run in "detached" mode via the `run:detached` Dokku command. Running a process in detached mode will immediately return a `CONTAINER_ID`. Detached containers are run without a tty and are also removed at the end of process execution.
Finally, a container can be run in "detached" mode via the `run:detached` Dokku command. Running a process in detached mode will immediately return the container name (or pod name when using the k3s scheduler). Detached containers run without a tty by default and are also removed at the end of process execution.
@@ -48,10 +48,30 @@ When running scheduled cron tasks, there are a few items to be aware of:
- Schedules are performed on the hosting server's timezone, which is typically UTC.
- At this time, only the `PATH` and `SHELL` environment variables are specified in the cron template.
- A `MAILTO` value can be set via the `cron:set` command.
- A `MAILFROM` value can be set via the `cron:set` command.
- Each scheduled task is executed within a one-off `run` container, and thus inherit any docker-options specified for `run` containers. Resources are never shared between scheduled tasks.
- Scheduled cron tasks are supported on a per-scheduler basis, and are currently only implemented by the `docker-local` scheduler.
- Tasks for _all_ apps managed by the `docker-local` scheduler are written to a single crontab file owned by the `dokku` user. The `dokku` user's crontab should be considered reserved for this purpose.
#### Specifying a MAILFROM value
> [!IMPORTANT]
> New as of 0.35.14
Users can specify a value for `MAILFROM` via the global `mailfrom` cron property by using the `cron:set` command.
All output for individual cron runs will be sent from the specified email.
Cron emails can be reset to use the system email by running the `cron:set` command for the global `mailfrom` property with no value.
```shell
dokku cron:set --global mailfrom
```
#### Specifying a MAILTO value
By default, cron tasks complete and do not perform any reporting. Users can specify a value for `MAILTO` via the global `mailto` cron property by using the `cron:set` command.
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.
