# History
## 0.37.2
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.37.2/bootstrap.sh
sudo DOKKU_TAG=v0.37.2 bash bootstrap.sh
```
### Bug Fixes
- #8198: @josegonzalez Ensure we continue on with logic if the error returned from fetching all apps is NoAppsExist
### Dependencies
- #8196: @dependabot[bot] chore(deps): bump byjg/easy-haproxy from 4.6.0 to 5.0.0 in /plugins/haproxy-vhosts
- #8197: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.31 to 2.11.32 in /plugins/scheduler-k3s
# History
## 0.37.1
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.37.1/bootstrap.sh
sudo DOKKU_TAG=v0.37.1 bash bootstrap.sh
```
### Bug Fixes
- #8186: @josegonzalez Update url to download golang
- #8155: @josegonzalez Sanitize vector sink values in report output
- #8156: @josegonzalez Do not start nginx if there are no apps with nginx as a proxy
- #8152: @josegonzalez Ensure keda usage does not cause jank in scaling deployments
### New Features
- #8154: @josegonzalez Enable live-restore by default when installing Dokku
- #8151: @josegonzalez Allow exposing non-web processes as kubernetes services
### Refactors
- #8149: @josegonzalez Remove nginx checks for functionality that always exists
### Documentation
- #8170: @znz Fix version in migration docs
- #8169: @josegonzalez Update logging in doc generation to enhance doc generation debugging
- #8153: @josegonzalez Fix reference to letsencrypt-server property
- #8150: @josegonzalez Clarify system requirements for k3s usage
- #8148: @josegonzalez Clarify plugin installation documentation
### Dependencies
- #8192: @dependabot[bot] chore(deps): bump golang from 1.25.4 to 1.25.5 in /tests/apps/go-fail-predeploy
- #8191: @dependabot[bot] chore(deps): bump golang from 1.25.4 to 1.25.5 in /tests/apps/go-fail-postdeploy
- #8189: @dependabot[bot] chore(deps): bump golang from 1.25.4 to 1.25.5 in /tests/apps/gogrpc
- #8193: @dependabot[bot] chore(deps): bump python from 3.14.0-alpine to 3.14.1-alpine in /docs/_build
- #8190: @dependabot[bot] chore(deps): bump golang from 1.25.4 to 1.25.5 in /tests/apps/zombies-dockerfile-no-tini
- #8188: @dependabot[bot] chore(deps): bump golang from 1.25.4 to 1.25.5 in /tests/apps/zombies-dockerfile-tini
- #8194: @dependabot[bot] chore(deps): bump python from 3.14.0-bookworm to 3.14.1-bookworm in /tests/apps/dockerfile-release
- #8195: @dependabot[bot] chore(deps): bump django from 5.2.8 to 5.2.9 in /tests/apps/dockerfile-release
- #8177: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/nodejs-express-noprocfile
- #8178: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/dockerfile-procfile-bad
- #8179: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/nodejs-express
- #8180: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/dockerfile-procfile
- #8181: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/gitsubmodules
- #8183: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/checks-root
- #8182: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/nodejs-express-noappjson
- #8184: @dependabot[bot] chore(deps): bump express from 5.1.0 to 5.2.1 in /tests/apps/dockerfile-app-json-formations
- #8172: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.14.2 to 4.14.3 in /docs/_build
- #8173: @dependabot[bot] chore(deps): bump werkzeug from 3.1.3 to 3.1.4 in /tests/apps/python-flask
- #8164: @dependabot[bot] chore(deps): bump body-parser from 2.2.0 to 2.2.1 in /tests/apps/checks-root
- #8165: @dependabot[bot] chore(deps): bump github.com/go-resty/resty/v2 from 2.16.5 to 2.17.0 in /plugins/scheduler-k3s
- #8167: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.17.1 to 10.17.2 in /docs/_build
- #8162: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.30 to 2.11.31 in /plugins/scheduler-k3s
- #8161: @dependabot[bot] chore(deps): bump github.com/fluxcd/pkg/kustomize from 1.23.0 to 1.24.0 in /plugins/scheduler-k3s
- #8159: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.19.0 to 3.19.2 in /plugins/scheduler-k3s
- #8158: @dependabot[bot] chore(deps): bump k8s.io/kubernetes from 1.34.1 to 1.34.2 in /plugins/scheduler-k3s
- #8143: @dependabot[bot] chore(deps): bump actions/checkout from 5 to 6
- #8145: @dependabot[bot] chore(deps): bump github.com/go-openapi/jsonpointer from 0.22.1 to 0.22.3 in /plugins/scheduler-k3s
- #8146: @dependabot[bot] chore(deps): bump k8s.io/kubectl from 0.34.1 to 0.34.2 in /plugins/scheduler-k3s
- #8144: @dependabot[bot] chore(deps): bump traefik from 3.6.1 to 3.6.2 in /plugins/traefik-vhosts
It is not sanitized in json format output as that is used for automation, but this should remove the need to redact any potentially sensitive information that users have in the sink, such as a token.
Closes#8147
If the values set by keda do not match the current deployment replicas value, the deployment object may be scaled in unexpected ways during a helm release. This change ensures keda will continue to manage that value correctly without the deployment object setting it back to something else.
# History
## 0.37.0
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.37.0/bootstrap.sh
sudo DOKKU_TAG=v0.37.0 bash bootstrap.sh
```
See the [0.37.0 migration guide](/docs/appendices/0.37.0-migration-guide.md) for more information on migrating to 0.37.0.
### Backwards Compatibility Breaks
- #8140: @josegonzalez Rename the scheduler-k3s:cluster-* commands to use a : instead of - for a delimiter
- #7982: @josegonzalez Remove references to pack being experimental
### Bug Fixes
- #8136: @josegonzalez Do not reset manually set port mappings when upgrading dokku
- #8114: @josegonzalez Ensure we can execute run commands when exec is executed as part of an entrypoint
- #8109: @josegonzalez Allow skipping the install trigger when installing a plugin
- #8104: @josegonzalez Drop deprecated aufs check
- #8100: @othercorey Add process-type label for run with procfile cmd
### New Features
- #8139: @josegonzalez Add aliases for select builder and scheduler plugins
- #8138: @josegonzalez Turn on buildpack trace mode when dokku trace is on
- #8137: @josegonzalez Add the ability to create k3s node profiles
- #8135: @josegonzalez Add support for git remotes with port specified inline
- #8112: @josegonzalez Implement cron and one-off run task TTLs
- #8106: @josegonzalez Support inline comments for app.json
- #8105: @josegonzalez Allow specifying kubelet-args when adding a new node to the cluster
- #8085: @josegonzalez Implement config:import command
- #8004: @Tashows Add buildpacks:detect subcommand
- #7991: @josegonzalez Add ability to pause/restart cron jobs
- #7989: @josegonzalez Add support to prevent overlapping execution of cron tasks
- #7986: @josegonzalez Add support for specifying CNB buildpacks via buildpacks command
- #7956: @josegonzalez Add a Railpack builder to Dokku
- #7608: @dragonhunt02 Add commands to proxy implementations for managing labels
### Refactors
- #8101: @josegonzalez Filter build docker-options correctly for each builder
### Documentation
- #8103: @josegonzalez Correct the release version for railpacks support
### Dependencies
- #8130: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.43.0 to 0.45.0 in /plugins/common
- #8110: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.76.0 to 1.77.0 in /tests/apps/gogrpc
- #8108: @dependabot[bot] chore(deps): bump js-yaml from 3.14.1 to 3.14.2 in /tests/apps/multi
- #8107: @dependabot[bot] chore(deps): bump click from 8.3.0 to 8.3.1 in /docs/_build
- #8098: @dependabot[bot] chore(deps): bump traefik from 3.5.4 to 3.6.1 in /plugins/traefik-vhosts
- #8097: @dependabot[bot] chore(deps): bump timberio/vector from 0.51.0-debian to 0.51.1-debian in /plugins/logs
- #8094: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.16.1 to 10.17.1 in /docs/_build
- #8092: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.23 to 9.7.0 in /docs/_build
- #8090: @dependabot[bot] chore(deps): bump sigs.k8s.io/kustomize/api from 0.20.1 to 0.21.0 in /plugins/scheduler-k3s
Node profiles can be used to specify repetitive options for clusters, making it easier to add specific types of instances quickly.
This PR additionally fixes kubelet-args specification - the same key can be specified multiple times, such as when specifying custom sysctl rules.
It can get repetitive to specify 'builder-' or 'scheduler-' prefixes for builder and scheduler commands. As these are mostly unique, Dokku now provides built-in aliases for the commands. Dokku still uses the long-form in all it's documentation, but these are a nice easter egg for determined users :)
Note that the null builder/scheduler plugins do not have aliases as they would shadow each other.
The jq binary doesn't support jsonc, so we can't modify it for testing purposes. Instead, just create an app.json with the correct heroku.postdeploy task.
During docker image generation, certain folders either do not exist or are symlinked in an odd fashion, causing the install trigger to fail. This is not the case at runtime, so we should defer the install trigger until container start and provide a method of skipping it when generating a docker image.
Closes#7308
We cannot grab a lock as cron:run with --detach will release the lock. Instead, just check if any containers for the specified cron_id are running and exit.
Without this, it is possible to keep an old build image around in the case of failed builds, and due to missing label support, the image will never be cleaned up.
# History
## 0.36.11
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.11/bootstrap.sh
sudo DOKKU_TAG=v0.36.11 bash bootstrap.sh
```
### Bug Fixes
- #8084: @josegonzalez Use the correct case for AS in Dockerfile
- #8083: @josegonzalez Use correct variable for tasks
- #8081: @josegonzalez Error out if the appname or app.json is missing when retrieving cron entries
### Refactors
- #8082: @josegonzalez Standardize naming in cron code
### Dependencies
- #8073: @dependabot[bot] chore(deps): bump timberio/vector from 0.50.0-debian to 0.51.0-debian in /plugins/logs
- #8080: @dependabot[bot] chore(deps): bump github.com/containerd/containerd from 1.7.28 to 1.7.29 in /plugins/scheduler-k3s
- #8079: @dependabot[bot] chore(deps): bump golang from 1.25.3 to 1.25.4 in /tests/apps/zombies-dockerfile-tini
- #8075: @dependabot[bot] chore(deps): bump golang from 1.25.3 to 1.25.4 in /tests/apps/go-fail-postdeploy
- #8078: @dependabot[bot] chore(deps): bump golang from 1.25.3 to 1.25.4 in /tests/apps/go-fail-predeploy
- #8077: @dependabot[bot] chore(deps): bump golang from 1.25.3 to 1.25.4 in /tests/apps/zombies-dockerfile-no-tini
- #8076: @dependabot[bot] chore(deps): bump golang from 1.25.3 to 1.25.4 in /tests/apps/gogrpc
- #8072: @dependabot[bot] chore(deps): update markdown requirement from <3.10,>=3.2.1 to >=3.2.1,<3.11 in /docs/_build
- #8074: @dependabot[bot] chore(deps): bump django from 5.2.7 to 5.2.8 in /tests/apps/dockerfile-release
- #8071: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.22 to 9.6.23 in /docs/_build
- #8068: @dependabot[bot] chore(deps): bump traefik from 3.5.3 to 3.5.4 in /plugins/traefik-vhosts
- #8069: @dependabot[bot] chore(deps): bump github.com/kedacore/keda/v2 from 2.18.0 to 2.18.1 in /plugins/scheduler-k3s
- #8066: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.29 to 2.11.30 in /plugins/scheduler-k3s
# History
## 0.36.10
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.10/bootstrap.sh
sudo DOKKU_TAG=v0.36.10 bash bootstrap.sh
```
### Bug Fixes
- #8063: @othercorey Use -t instead of deprecated --time in stop commands
- #8058: @josegonzalez Ensure the pre-receive hook and URLS files are correct when cloning or renaming apps
- #8059: @josegonzalez Expand variables for release tasks
- #8060: @josegonzalez Use updated http2 directive for setting http2 support
### Documentation
- #8051: @othercorey Fix "its" in Caddy SSL configuration documentation
### Dependencies
- #8065: @dependabot[bot] chore(deps): bump actions/upload-artifact from 4 to 5
- #8064: @dependabot[bot] chore(deps): bump actions/download-artifact from 5 to 6
- #8057: @dependabot[bot] chore(deps): bump node from 24-alpine to 25-alpine in /tests/apps/dockerfile-procfile-bad
- #8056: @dependabot[bot] chore(deps): bump node from 24-alpine to 25-alpine in /tests/apps/dockerfile-app-json-formations
- #8055: @dependabot[bot] chore(deps): bump node from 24-alpine to 25-alpine in /tests/apps/dockerfile-procfile
- #8054: @dependabot[bot] chore(deps): bump node from 24-alpine to 25-alpine in /tests/apps/dockerfile
- #8053: @dependabot[bot] chore(deps): bump node from 24-alpine to 25-alpine in /tests/apps/dockerfile-noexpose
Procfile commands need to be expanded with actual environment variables as procfile-util will otherwise empty them out. This doesn't happen for app.json scripts as they are never expanded until the docker container gets created.
Closes#8050
# History
## 0.36.9
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.9/bootstrap.sh
sudo DOKKU_TAG=v0.36.9 bash bootstrap.sh
```
### Bug Fixes
- #8032: @josegonzalez Set correct labels for tests/apps/dockerfile-release pip updates
### New Features
- #8047: @josegonzalez Add ability to disable letsencrypt for a given application or globally
### Dependencies
- #8049: @dependabot[bot] chore(deps): bump github.com/cert-manager/cert-manager from 1.19.0 to 1.19.1 in /plugins/scheduler-k3s
- #8048: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.21 to 9.6.22 in /docs/_build
- #8042: @dependabot[bot] chore(deps): bump django from 5.1.13 to 5.2.7 in /tests/apps/dockerfile-release
- #8043: @dependabot[bot] chore(deps): bump whitenoise from 6.2.0 to 6.11.0 in /tests/apps/dockerfile-release
- #8044: @dependabot[bot] chore(deps): bump djangorestframework from 3.15.2 to 3.16.1 in /tests/apps/dockerfile-release
- #8045: @dependabot[bot] chore(deps): bump psycopg2-binary from 2.9.5 to 2.9.11 in /tests/apps/dockerfile-release
- #8046: @dependabot[bot] chore(deps): bump dj-database-url from 1.0.0 to 3.0.1 in /tests/apps/dockerfile-release
- #8041: @dependabot[bot] chore(deps): bump golang from 1.25.2 to 1.25.3 in /tests/apps/gogrpc
- #8040: @dependabot[bot] chore(deps): bump golang from 1.25.2 to 1.25.3 in /tests/apps/go-fail-predeploy
- #8039: @dependabot[bot] chore(deps): bump golang from 1.25.2 to 1.25.3 in /tests/apps/zombies-dockerfile-no-tini
- #8037: @dependabot[bot] chore(deps): bump golang from 1.25.2 to 1.25.3 in /tests/apps/go-fail-postdeploy
- #8038: @dependabot[bot] chore(deps): bump golang from 1.25.2 to 1.25.3 in /tests/apps/zombies-dockerfile-tini
- #8036: @dependabot[bot] chore(deps): bump actions/setup-node from 5 to 6
- #8033: @dependabot[bot] chore(deps): bump github.com/gofrs/flock from 0.12.1 to 0.13.0 in /plugins/scheduler-k3s
- #8034: @dependabot[bot] chore(deps): bump github.com/kedacore/keda/v2 from 2.17.1-0.20250708210620-a239d2459a35 to 2.18.0 in /plugins/scheduler-k3s
# History
## 0.36.8
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.8/bootstrap.sh
sudo DOKKU_TAG=v0.36.8 bash bootstrap.sh
```
### Bug Fixes
- #8031: @josegonzalez Respect the k3s master node version when adding a new worker to the k3s cluster
- #7990: @josegonzalez Correct parsing of the --container-id flag for the enter command
### Documentation
- #8013: @othercorey Change command to add SSH key with sudo
- #7998: @bakatz Remove incorrect documentation about --envfile flag for config:export
### Dependencies
- #8028: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.42.0 to 0.43.0 in /plugins/common
- #8015: @dependabot[bot] chore(deps): bump github.com/cert-manager/cert-manager from 1.18.2 to 1.19.0 in /plugins/scheduler-k3s
- #8029: @dependabot[bot] chore(deps): bump github.com/gofrs/flock from 0.12.1 to 0.13.0 in /plugins/ps
- #8011: @dependabot[bot] chore(deps): bump org.apache.maven.plugins:maven-dependency-plugin from 3.8.1 to 3.9.0 in /tests/apps/java
- #8012: @dependabot[bot] chore(deps): bump click from 8.1.8 to 8.3.0 in /docs/_build
- #8014: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.75.1 to 1.76.0 in /tests/apps/gogrpc
- #8018: @dependabot[bot] chore(deps): bump github/codeql-action from 3 to 4
- #8019: @dependabot[bot] chore(deps): bump golang from 1.25.1 to 1.25.2 in /tests/apps/zombies-dockerfile-no-tini
- #8020: @dependabot[bot] chore(deps): bump golang from 1.25.1 to 1.25.2 in /tests/apps/go-fail-predeploy
- #8021: @dependabot[bot] chore(deps): bump python from 3.13.7-bookworm to 3.14.0-bookworm in /tests/apps/dockerfile-release
- #8022: @dependabot[bot] chore(deps): bump golang from 1.25.1 to 1.25.2 in /tests/apps/gogrpc
- #8024: @dependabot[bot] chore(deps): bump golang from 1.25.1 to 1.25.2 in /tests/apps/zombies-dockerfile-tini
- #8023: @dependabot[bot] chore(deps): bump golang from 1.25.1 to 1.25.2 in /tests/apps/go-fail-postdeploy
- #8025: @dependabot[bot] chore(deps): bump python from 3.13.7-alpine to 3.14.0-alpine in /docs/_build
- #8026: @dependabot[bot] chore(deps): bump github.com/fluxcd/pkg/kustomize from 1.22.0 to 1.23.0 in /plugins/scheduler-k3s
- #8027: @dependabot[bot] chore(deps): bump ruby from 3.4.6 to 3.4.7 in /tests/apps/dockerfile-entrypoint
- #8030: @dependabot[bot] chore(deps): bump rack from 2.2.19 to 2.2.20 in /tests/apps/ruby
- #8016: @dependabot[bot] chore(deps): bump rack from 2.2.18 to 2.2.19 in /tests/apps/ruby
- #8009: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.9 to 1.36.10 in /tests/apps/gogrpc
- #7994: @dependabot[bot] chore(deps): bump timberio/vector from 0.49.0-debian to 0.50.0-debian in /plugins/logs
- #8006: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.20 to 9.6.21 in /docs/_build
- #8003: @dependabot[bot] chore(deps): bump traefik from 3.5.2 to 3.5.3 in /plugins/traefik-vhosts
- #7996: @dependabot[bot] chore(deps): bump pyyaml from 6.0.2 to 6.0.3 in /docs/_build
- #8000: @dependabot[bot] chore(deps): bump markupsafe from 3.0.2 to 3.0.3 in /docs/_build
- #8001: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.13.5 to 4.14.2 in /docs/_build
- #8002: @dependabot[bot] chore(deps): bump github.com/go-openapi/jsonpointer from 0.22.0 to 0.22.1 in /plugins/scheduler-k3s
- #7995: @dependabot[bot] chore(deps): bump rack from 2.2.17 to 2.2.18 in /tests/apps/ruby
- #7992: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 3.2.0 to 3.3.0
- #7993: @dependabot[bot] chore(deps): bump pyparsing from 3.2.4 to 3.2.5 in /docs/_build
- #7987: @dependabot[bot] chore(deps): bump ruby from 3.4.5 to 3.4.6 in /tests/apps/dockerfile-entrypoint
- #7983: @dependabot[bot] chore(deps): bump k8s.io/kubernetes from 1.34.0 to 1.34.1 in /plugins/scheduler-k3s
- #7984: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.19 to 9.6.20 in /docs/_build
- #7985: @dependabot[bot] chore(deps): bump pyparsing from 3.2.3 to 3.2.4 in /docs/_build
### Other
- #8008: @dependabot[bot] chore(deps): bump django from 5.1.12 to 5.1.13 in /tests/apps/dockerfile-release
Previously, it was possible to have a kubernetes version mismatch on new worker nodes if a newer version of kubernetes was released prior to upgrading the master nodes to that version. This can sometimes cause cluster instability.
This change fetches the lowest node version associated with a master node and then uses that to install k3s on the worker node.
# History
## 0.36.7
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.7/bootstrap.sh
sudo DOKKU_TAG=v0.36.7 bash bootstrap.sh
```
### Bug Fixes
- #7981: @josegonzalez Only install software-properties-common on Ubuntu and older Debian installations
- #7979: @josegonzalez Skip invalid apps when listing applications
- #7977: @kminek Remove server_tokens directive from main nginx config if present (com…
- #7974: @josegonzalez Ensure lsb_release is available on debian systems
### New Features
- #7978: @josegonzalez Add ability to list global cron tasks
- #7975: @josegonzalez Create SecurityContext for k3s scheduler from docker-options
### Dependencies
- #7972: @dependabot[bot] chore(deps): bump k8s.io/kubectl from 0.34.0 to 0.34.1 in /plugins/scheduler-k3s
- #7973: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.18.6 to 3.19.0 in /plugins/scheduler-k3s
- #7971: @dependabot[bot] chore(deps): bump k8s.io/client-go from 0.34.0 to 0.34.1 in /plugins/scheduler-k3s
- #7970: @dependabot[bot] chore(deps): bump k8s.io/api from 0.34.0 to 0.34.1 in /plugins/scheduler-k3s
- #7966: @dependabot[bot] chore(deps): bump github.com/fluxcd/pkg/kustomize from 1.19.0 to 1.22.0 in /plugins/scheduler-k3s
- #7963: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.75.0 to 1.75.1 in /tests/apps/gogrpc
- #7964: @dependabot[bot] chore(deps): bump traefik from 3.5.1 to 3.5.2 in /plugins/traefik-vhosts
- #7965: @dependabot[bot] chore(deps): bump k8s.io/apimachinery from 0.34.0 to 0.34.1 in /plugins/scheduler-k3s
- #7961: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.41.0 to 0.42.0 in /plugins/common
- #7960: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.8 to 1.36.9 in /tests/apps/gogrpc
### Other
- #7968: @josegonzalez chore: bump herokuish version from 0.11.0 to 0.11.3
- #7962: @dependabot[bot] chore(deps): bump django from 5.1.10 to 5.1.12 in /tests/apps/dockerfile-release
The previous method ended up validating the app name when checking if the app was deployed or not, which isn't necessary as that should only be performed at the command-level.
# History
## 0.36.6
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.6/bootstrap.sh
sudo DOKKU_TAG=v0.36.6 bash bootstrap.sh
```
### Bug Fixes
- #7955: @josegonzalez Ensure that the nixpacks bin is installed in /usr/bin/nixpacks in Docker image
- #7953: @josegonzalez Set correct label for nixpacks builder
- #7942: @josegonzalez Ensure the code is copied over to the new app on clone or rebase
- #7941: @josegonzalez Do not generate an https url when there is no SSL certificate
- #7940: @josegonzalez Silence openresty extract warnings during the deploy process
### Tests
- #7954: @josegonzalez Respect DOKKU_DOMAIN when deploying in tests
- #7943: @josegonzalez Remove unused test app
- #7939: @josegonzalez Add test for ensuring run commands work with pack-based builds
### Dependencies
- #7958: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.18.5 to 3.18.6 in /plugins/scheduler-k3s
- #7952: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.16.0 to 0.17.0 in /plugins/common
- #7951: @dependabot[bot] chore(deps): bump golang from 1.25.0 to 1.25.1 in /tests/apps/gogrpc
- #7950: @dependabot[bot] chore(deps): bump golang from 1.25.0 to 1.25.1 in /tests/apps/go-fail-postdeploy
- #7949: @dependabot[bot] chore(deps): bump golang from 1.25.0 to 1.25.1 in /tests/apps/zombies-dockerfile-no-tini
- #7947: @dependabot[bot] chore(deps): bump golang from 1.25.0 to 1.25.1 in /tests/apps/zombies-dockerfile-tini
- #7945: @dependabot[bot] chore(deps): bump golang from 1.25.0 to 1.25.1 in /tests/apps/go-fail-predeploy
- #7946: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.18 to 9.6.19 in /docs/_build
# History
## 0.36.5
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.5/bootstrap.sh
sudo DOKKU_TAG=v0.36.5 bash bootstrap.sh
```
### New Features
- #7937: @josegonzalez Add support for Debian Trixie
# History
## 0.36.4
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.4/bootstrap.sh
sudo DOKKU_TAG=v0.36.4 bash bootstrap.sh
```
### Bug Fixes
- #7914: @josegonzalez Fix nginx configuration building in k3s scheduler
### Dependencies
- #7935: @dependabot[bot] chore(deps): update markdown requirement from <3.9,>=3.2.1 to >=3.2.1,<3.10 in /docs/_build
- #7936: @dependabot[bot] chore(deps): bump github.com/go-openapi/jsonpointer from 0.21.2 to 0.22.0 in /plugins/scheduler-k3s
- #7931: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.28 to 2.11.29 in /plugins/scheduler-k3s
- #7932: @dependabot[bot] chore(deps): bump actions/setup-python from 5 to 6
- #7933: @dependabot[bot] chore(deps): bump actions/setup-node from 4 to 5
- #7934: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 3.1.0 to 3.2.0
- #7920: @dependabot[bot] chore(deps): bump github.com/spf13/pflag from 1.0.9 to 1.0.10 in /plugins/common
- #7887: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.38.0 to 1.38.2 in /plugins/common
- #7847: @dependabot[bot] chore(deps): bump timberio/vector from 0.48.0-debian to 0.49.0-debian in /plugins/logs
- #7890: @dependabot[bot] chore(deps): bump k8s.io/kubernetes from 1.33.2 to 1.34.0 in /plugins/scheduler-k3s
- #7881: @dependabot[bot] chore(deps): bump byjg/easy-haproxy from 4.5.0 to 4.6.0 in /plugins/haproxy-vhosts
- #7880: @dependabot[bot] chore(deps): bump beautifulsoup4 from 4.13.4 to 4.13.5 in /docs/_build
- #7888: @dependabot[bot] chore(deps): bump soupsieve from 2.7 to 2.8 in /docs/_build
- #7902: @dependabot[bot] chore(deps): bump github.com/spf13/pflag from 1.0.7 to 1.0.9 in /plugins/common
- #7891: @dependabot[bot] chore(deps): bump k8s.io/kubectl from 0.33.3 to 0.34.0 in /plugins/scheduler-k3s
- #7895: @dependabot[bot] chore(deps): bump traefik from 3.5.0 to 3.5.1 in /plugins/traefik-vhosts
These shadow existing values managed by k3s itself, causing issues where the same header is injected with multiple values, which some frameworks do not support as they use the header directly without parsing to construct urls.
# History
## 0.36.3
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.3/bootstrap.sh
sudo DOKKU_TAG=v0.36.3 bash bootstrap.sh
```
### New Features
- #7878: @josegonzalez Allow specifying base64-encoded values in vector-sink DSN urls
### Dependencies
- #7873: @dependabot[bot] chore(deps): bump github.com/go-openapi/jsonpointer from 0.21.1 to 0.21.2 in /plugins/scheduler-k3s
- #7874: @dependabot[bot] chore(deps): bump k8s.io/api from 0.33.3 to 0.33.4 in /plugins/scheduler-k3s
- #7875: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.17 to 9.6.18 in /docs/_build
# History
## 0.36.2
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.2/bootstrap.sh
sudo DOKKU_TAG=v0.36.2 bash bootstrap.sh
```
### Bug Fixes
- #7872: @josegonzalez Correct issues when scaling non-web processes for the scheduler-k3s plugin
### Refactors
- #7871: @josegonzalez Remove public exposure of DOKKU_APP_TYPE in favor of builder detected property
### Dependencies
- #7868: @dependabot[bot] chore(deps): bump grunt-cli from 1.4.3 to 1.5.0 in /tests/apps/multi
- #7869: @dependabot[bot] chore(deps): bump bower from 1.8.12 to 1.8.14 in /tests/apps/multi
- #7870: @dependabot[bot] chore(deps): bump tmp from 0.2.4 to 0.2.5 in /tests/apps/multi
- #7867: @dependabot[bot] chore(deps): bump grunt from 1.5.3 to 1.6.1 in /tests/apps/multi
- #7866: @dependabot[bot] chore(deps): bump github.com/fluxcd/pkg/kustomize from 1.18.0 to 1.19.0 in /plugins/scheduler-k3s
- #7862: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.7 to 1.36.8 in /tests/apps/gogrpc
### Other
- #7864: @josegonzalez chore(deps): add dependabot entries for plugins/scheduler-k3s and tests/apps/multi
The DOKKU_APP_TYPE has long since ceased to be the correct way to specify the builder for the application. It's only usage has been during the detection phase, specifically to ensure that the herokuish plugin injects the correct docker arguments during the build. As such, it is safe to migrate away to a property in a patch release.
Users that seek to set a specific builder should use 'dokku builder:set $APP selected' instead.
Refs #7863
# History
## 0.36.1
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.1/bootstrap.sh
sudo DOKKU_TAG=v0.36.1 bash bootstrap.sh
```
### Bug Fixes
- #7846: @josegonzalez Correct issue in parsing escaped plus signs in vector sink values
- #7841: @leksyib14 Fix handling of equals sign in vector sink values
- #7844: @josegonzalez Do not change permissions on config directory symlinks
### Tests
- #7848: @josegonzalez Ensure tests properly fetch data from json output
- #7845: @josegonzalez Use the official github actions arm64 runner
### Dependencies
- #7861: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.74.2 to 1.75.0 in /tests/apps/gogrpc
- #7860: @dependabot[bot] chore(deps): bump flask from 3.1.1 to 3.1.2 in /tests/apps/python-flask
- #7859: @dependabot[bot] chore(deps): bump flask from 3.1.1 to 3.1.2 in /tests/apps/multi
- #7856: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.16 to 9.6.17 in /docs/_build
- #7857: @dependabot[bot] chore(deps): bump python from 3.13.6-alpine to 3.13.7-alpine in /docs/_build
- #7858: @dependabot[bot] chore(deps): bump python from 3.13.6-bookworm to 3.13.7-bookworm in /tests/apps/dockerfile-release
- #7855: @dependabot[bot] chore(deps): bump org.eclipse.jetty:jetty-servlet from 11.0.25 to 11.0.26 in /tests/apps/java
- #7849: @dependabot[bot] chore(deps): bump golang from 1.24.6 to 1.25.0 in /tests/apps/zombies-dockerfile-tini
- #7850: @dependabot[bot] chore(deps): bump golang from 1.24.6 to 1.25.0 in /tests/apps/go-fail-predeploy
- #7851: @dependabot[bot] chore(deps): bump golang from 1.24.6 to 1.25.0 in /tests/apps/go-fail-postdeploy
- #7852: @dependabot[bot] chore(deps): bump golang from 1.24.6 to 1.25.0 in /tests/apps/gogrpc
- #7853: @dependabot[bot] chore(deps): bump golang from 1.24.6 to 1.25.0 in /tests/apps/zombies-dockerfile-no-tini
- #7842: @dependabot[bot] chore(deps): bump actions/checkout from 4 to 5
- #7821: @dependabot[bot] chore(deps): bump traefik from 3.4.4 to 3.5.0 in /plugins/traefik-vhosts
- #7843: @josegonzalez Bump go modules
- #7824: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.15 to 9.6.16 in /docs/_build
- #7823: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.16 to 10.16.1 in /docs/_build
- #7831: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.6 to 1.36.7 in /tests/apps/gogrpc
- #7839: @dependabot[bot] chore(deps): bump python from 3.13.5-bookworm to 3.13.6-bookworm in /tests/apps/dockerfile-release
- #7838: @dependabot[bot] chore(deps): bump python from 3.13.5-alpine to 3.13.6-alpine in /docs/_build
- #7837: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.40.0 to 0.41.0 in /plugins/common
- #7836: @dependabot[bot] chore(deps): bump golang from 1.24.5 to 1.24.6 in /tests/apps/zombies-dockerfile-tini
- #7835: @dependabot[bot] chore(deps): bump golang from 1.24.5 to 1.24.6 in /tests/apps/zombies-dockerfile-no-tini
- #7834: @dependabot[bot] chore(deps): bump golang from 1.24.5 to 1.24.6 in /tests/apps/go-fail-postdeploy
- #7833: @dependabot[bot] chore(deps): bump golang from 1.24.5 to 1.24.6 in /tests/apps/gogrpc
- #7832: @dependabot[bot] chore(deps): bump golang from 1.24.5 to 1.24.6 in /tests/apps/go-fail-predeploy
- #7828: @dependabot[bot] chore(deps): bump actions/download-artifact from 4 to 5
### Other
- #7854: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.18.4 to 3.18.5 in /plugins/scheduler-k3s
- #7825: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.26 to 2.11.28 in /plugins/scheduler-k3s
- #7830: @dependabot[bot] chore(deps): bump tmp from 0.2.1 to 0.2.4 in /tests/apps/multi
- #7829: @dependabot[bot] chore(deps): bump github.com/go-acme/lego/v4 from 4.24.0 to 4.25.2 in /plugins/scheduler-k3s
# History
## 0.36.0
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.36.0/bootstrap.sh
sudo DOKKU_TAG=v0.36.0 bash bootstrap.sh
```
See the [0.36.0 migration guide](/docs/appendices/0.36.0-migration-guide.md) for more information on migrating to 0.36.0.
This standardizes the extraction code and makes it easier to reuse in future implementations of file extraction.
Additionally, this adds a way to extract folders from codebases.
- Replace boolean return values with proper error handling in dockerTag and dockerPush functions
- Add detailed error context including Docker command exit codes and stderr output
- Remove TODO comments and improve error messages for better debugging
- Fix error message formatting in defer function
This addresses the TODO comments for better error handling and provides
users with actionable error information when Docker registry operations fail.
Closes: #XXXX
Rather than redeploy every formation, only deploy formations that have had their values changed from the defaults.
This still doesn't handle the case where we touch existing processes when scaling _up_, but should decrease the number of services touched otherwise during scaling.
Also note that there are no tests for this new behavior yet (tests incoming).
Refs #7396
Without this, we try to write the config for the app even though it doesn't exist anymore, causing issues with deleting apps with invalid cron configs.
# History
## 0.35.20
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.20/bootstrap.sh
sudo DOKKU_TAG=v0.35.20 bash bootstrap.sh
```
### Bug Fixes
- #7726: @josegonzalez Ensure compose projects are spawned from the /tmp directory
- #7725: @josegonzalez Uninstall hashicorp tap to fix formula releases
### Dependencies
- #7735: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.72.2 to 1.73.0 in /tests/apps/gogrpc
- #7737: @dependabot[bot] chore(deps): bump python from 3.13.3-alpine to 3.13.4-alpine in /docs/_build
- #7738: @dependabot[bot] chore(deps): bump python from 3.13.3-bookworm to 3.13.4-bookworm in /tests/apps/dockerfile-release
- #7745: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.38.0 to 0.39.0 in /plugins/common
- #7740: @dependabot[bot] chore(deps): bump golang from 1.24.3 to 1.24.4 in /tests/apps/gogrpc
- #7741: @dependabot[bot] chore(deps): bump golang from 1.24.3 to 1.24.4 in /tests/apps/go-fail-postdeploy
- #7742: @dependabot[bot] chore(deps): bump golang from 1.24.3 to 1.24.4 in /tests/apps/zombies-dockerfile-tini
- #7743: @dependabot[bot] chore(deps): bump golang from 1.24.3 to 1.24.4 in /tests/apps/go-fail-predeploy
- #7744: @dependabot[bot] chore(deps): bump golang from 1.24.3 to 1.24.4 in /tests/apps/zombies-dockerfile-no-tini
- #7730: @dependabot[bot] chore(deps): bump traefik from 3.4.0 to 3.4.1 in /plugins/traefik-vhosts
- #7729: @dependabot[bot] chore(deps): bump zipp from 3.21.0 to 3.22.0 in /docs/_build
- #7727: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.72.1 to 1.72.2 in /tests/apps/gogrpc
### Other
- #7746: @dependabot[bot] chore(deps): bump django from 5.0.14 to 5.1.10 in /tests/apps/dockerfile-release
- #7731: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.24 to 2.11.25 in /plugins/scheduler-k3s
A recent update to compose executes a stat call in the current working directory, which may have incorrect permissions for execution once the user is changed to the dokku user. This change forces all compose commands to execute in the /tmp directory by using a helper function to execute compose up/down.
Closes#7705
# History
## 0.35.19
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.35.19/bootstrap.sh
sudo DOKKU_TAG=v0.35.19 bash bootstrap.sh
```
### Bug Fixes
- #7686: @josegonzalez Untap aws/tap to correct issues in formula release
### Documentation
- #7707: @swrobel Remove duplicate hostname plugin
- #7687: @d9i Fix cron key in app.json docs
- #7677: @plafue Add continuous integration example for woodpecker ci
### Tests
- #7585: @josegonzalez Add test to prove Dokku respects the Procfile when deploying from an image
- #7678: @josegonzalez Revert "fix: update CID count in ps tests"
### Dependencies
- #7692: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.37.0 to 0.38.0 in /plugins/common
- #7626: @dependabot[bot] chore(deps): bump express from 4.21.2 to 5.1.0 in /tests/apps/dockerfile
- #7693: @dependabot[bot] chore(deps): bump traefik from 3.3.5 to 3.4.0 in /plugins/traefik-vhosts
- #7694: @dependabot[bot] chore(deps): bump golang from 1.24.2 to 1.24.3 in /tests/apps/go-fail-postdeploy
- #7695: @dependabot[bot] chore(deps): bump node from 23-alpine to 24-alpine in /tests/apps/dockerfile-procfile-bad
- #7696: @dependabot[bot] chore(deps): bump golang from 1.24.2 to 1.24.3 in /tests/apps/gogrpc
- #7697: @dependabot[bot] chore(deps): bump golang from 1.24.2 to 1.24.3 in /tests/apps/go-fail-predeploy
- #7698: @dependabot[bot] chore(deps): bump node from 23-alpine to 24-alpine in /tests/apps/dockerfile-procfile
- #7699: @dependabot[bot] chore(deps): bump golang from 1.24.2 to 1.24.3 in /tests/apps/zombies-dockerfile-no-tini
- #7700: @dependabot[bot] chore(deps): bump golang from 1.24.2 to 1.24.3 in /tests/apps/zombies-dockerfile-tini
- #7701: @dependabot[bot] chore(deps): bump node from 23-alpine to 24-alpine in /tests/apps/dockerfile
- #7702: @dependabot[bot] chore(deps): bump node from 23-alpine to 24-alpine in /tests/apps/dockerfile-app-json-formations
- #7704: @dependabot[bot] chore(deps): bump rack from 2.2.13 to 2.2.14 in /tests/apps/ruby
- #7711: @dependabot[bot] chore(deps): bump flask from 3.1.0 to 3.1.1 in /tests/apps/multi
- #7712: @dependabot[bot] chore(deps): bump flask from 3.1.0 to 3.1.1 in /tests/apps/python-flask
- #7713: @dependabot[bot] chore(deps): bump pyyaml-env-tag from 0.1 to 1.1 in /docs/_build
- #7714: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.12 to 9.6.14 in /docs/_build
- #7715: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.72.0 to 1.72.1 in /tests/apps/gogrpc
- #7716: @dependabot[bot] chore(deps): bump ruby from 3.4.3 to 3.4.4 in /tests/apps/dockerfile-entrypoint
- #7718: @dependabot[bot] chore(deps): bump timberio/vector from 0.46.1-debian to 0.47.0-debian in /plugins/logs
- #7703: @dependabot[bot] chore(deps): bump node from 23-alpine to 24-alpine in /tests/apps/dockerfile-noexpose
- #7688: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.14.3 to 10.15 in /docs/_build
- #7689: @dependabot[bot] chore(deps): bump importlib-metadata from 8.6.1 to 8.7.0 in /docs/_build
- #7671: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.36.0 to 0.38.0 in /tests/apps/gogrpc
- #7681: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.71.1 to 1.72.0 in /tests/apps/gogrpc
- #7680: @dependabot[bot] chore(deps): bump soupsieve from 2.6 to 2.7 in /docs/_build
- #7682: @dependabot[bot] chore(deps): bump packaging from 24.2 to 25.0 in /docs/_build
- #7673: @dependabot[bot] chore(deps): bump golang.org/x/net from 0.37.0 to 0.38.0 in /plugins/common
- #7675: @dependabot[bot] chore(deps): bump byjg/easy-haproxy from 4.4.0 to 4.5.0 in /plugins/haproxy-vhosts
- #7676: @dependabot[bot] chore(deps): bump mkdocs-material from 9.6.11 to 9.6.12 in /docs/_build
### Other
- #7723: @josegonzalez Revert "chore(deps): bump helm.sh/helm/v3 from 3.14.2 to 3.17.3 in /plugins/scheduler-k3s"
- #7645: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.14.2 to 3.17.3 in /plugins/scheduler-k3s
- #7717: @dependabot[bot] chore(deps): bump setuptools from 70.0.0 to 78.1.1 in /tests/apps/dockerfile-release
- #7719: @d1ceward Fix: Add missing `systemctl` path detection in nginx-vhost plugin
- #7679: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.15 to 2.11.24 in /plugins/scheduler-k3s
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.
plugin:disable <name> # Disable an installed plugin (third-party only)
plugin:enable <name> # Enable a previously disabled plugin
plugin:install [--core|git-url] [--committish branch|commit|tag] [--name custom-plugin-name] # Optionally download git-url (and pin to the specified branch/commit/tag) & run install trigger for active plugins (or only core ones)
plugin:install [--core|git-url] [--committish branch|commit|tag] [--name custom-plugin-name] [--skip-install-trigger] # Optionally download git-url (and pin to the specified branch/commit/tag) & run install trigger for active plugins (or only core ones)
plugin:installed <name> # Checks if a plugin is installed
plugin:install-dependencies [--core] # Run install-dependencies trigger for active plugins (or only core ones)
plugin:list # Print active plugins
@@ -36,35 +36,35 @@ dokku plugin:list
```
plugn: dev
00_dokku-standard 0.35.18 enabled dokku core standard plugin
- The `plugin:list` command no longer outputs the version for the `plugn` binary.
- Users building docker images that run Dokku will need to use a new sudoer wrapper for the `docker-image-labeler` binary to work correctly. A reference version has been placed in the `docker` skeleton directory. This should only impact platform developers, and users of our Docker image will already have the file available.
- The `dokku` user's cron is now in use by Dokku itself. Customizations will be overwritten. Users are encouraged to use a cron entry in`/etc/cron.d/dokku` to avoid this issue.
- The `dokku` user's cron is now in use by Dokku itself. Customizations will be overwritten. Users are encouraged to use a cron file at`/etc/cron.d/dokku` to avoid this issue.
- As of 0.23.0, Dokku will now inject the `max-size` log driver option for applications. This is restricted to app-configured log driver values empty, `local` or `json-file` in 0.23.1 to increase setup compatibility. Users who configure alternative log drivers at the system level will need to either set the global `max-size` property to `unlimited` or switch to the built-in `vector` logging support.
- Process stop timeouts are now configured via the `ps` property `stop-timeout-seconds`. Existing `DOKKU_DOCKER_STOP_TIMEOUT` environment variables will be automatically migrated to the new value.
- Processes now default to a `30` second stop timeout.
- The `domains:clear` command no longer runs domain setup after clearing the domains. Use `domains:reset` or run `domains:setup` manually to have the same effect.
- The deprecated `DOKKU_DISABLE_ANSI_PREFIX_REMOVAL` setting has been removed. Dokku deploys no longer use shell escape codes to modify output, and thus deploy output may now contain `remote:` as a prefix in each lines output.
## Deprecations
Ubuntu 20.04 is now a deprecated installation target. The operating system will be considered EOL by Canonical in April 2025. Users are encouraged to upgrade to Ubuntu 24.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.
- The `app.json` file format is now parsed as JSONC and supports inline comments.
- The `scheduler-k3s:cluster-add` command is now `scheduler-k3s:cluster:add`.
- The `scheduler-k3s:cluster-list` command is now `scheduler-k3s:cluster:list`.
- The `scheduler-k3s:cluster-remove` command is now `scheduler-k3s:cluster:remove`.
## Removals
- Support for the `DOKKU_DOCKERFILE_CACHE_BUILD` environment variable has been removed. Use the `docker-options` plugin to set build arguments for your app instead.
- Support for the `DOKKU_DOCKER_BUILD_OPTS` environment variable has been removed. Use the `docker-options` plugin to set build arguments for your app instead.
- Support for the `no-cache` nixpacks property has been removed. Use the `docker-options` plugin to set build arguments for your app instead.
- Support for customizing the label-key for the caddy proxy has been removed. Always use `caddy.` as a prefix for your caddy directives.
(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:
The `railpack.json` file is used to configure an application when built with the `railpack` builder. Please refer to the [railpack.json documentation](https://railpack.com/config/file) for more information.
See [documentation here](https://github.com/SebastianSzturo/dokku-cli) for more information.
## (ruby) DokkuClient
DokkuClient is another rubygem that acts as a client for your Dokku installation with built-in support for certain external plugins. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dokku_client
```
See [documentation here](https://github.com/netguru/dokku_client) for more information.
## (ruby) Dokkufy
Dokkufy is a rubygem that handles automation of certain tasks, such as Dokku setup, plugin installation, etc. You can install it via the following shell command (assuming you have ruby and rubygems installed):
```shell
gem install dokkufy
```
See [documentation here](https://github.com/cbetta/dokkufy) for more information.
## (ruby) Dockland
Dockland 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):
| `DOKKU_APP_SHELL` | `/bin/bash` | `dokku config:set` | Allows users to change the default shell used by Dokku for `dokku enter` and execution of deployment tasks. |
| `DOKKU_APP_TYPE` | `herokuish` | Auto-detected by using buildpacks or dockerfile | |
@@ -110,10 +109,7 @@ The following config variables have special meanings and can be set in a variety
| `DOKKU_CHECKS_ATTEMPTS` | `5` | `dokku config:set` | Number of retries for to run for a specific check before marking it as a failure
| `DOKKU_DEFAULT_CHECKS_WAIT` | `10` | `dokku config:set` | 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_DISABLE_PROXY` | none | `dokku proxy:disable` <br /> `dokku proxy:enable` | Disables the proxy in front of your application, resulting in publicly routing the docker container. |
| `DOKKU_DISABLE_ANSI_PREFIX_REMOVAL` | none | `dokku config:set` <br /> `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*` | Disables removal of the ANSI prefix during deploys. Can be used in cases where the client deployer does not understand ansi escape codes. |
| `DOKKU_DISABLE_APP_AUTOCREATION` | none | `dokku config:set` | Disables automatic creation of a non-existent app on deploy. |
| `DOKKU_DOCKER_STOP_TIMEOUT` | `10` | `dokku config:set` | 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.|
> Please check the documentation for your particular buildpack as you may need to include configuration files (such as a Procfile) in your project root.
To add a custom buildpack, use the `buildpacks:add` command:
In some cases, it may be necessary to swap out a given buildpack. Rather than needing to re-specify each buildpack, the `buildpacks:set` command can be used to overwrite a buildpack at a given position.
By default, this will overwrite the _first_ buildpack specified. To specify an index, the `--index` flag may be used. This flag is specified starting at a 1-index value, and defaults to `1`.
Buildpacks can also be removed by index via the `--index` flag. This flag is specified starting at a 1-index value.
```shell
dokku buildpacks:remove node-js-app --index 1
```
### Clearing all buildpacks
> This does not affect automatically detected buildpacks, nor does it impact any specified `BUILDPACK_URL` environment variable.
The `buildpacks:clear` command can be used to clear all configured buildpacks for a specified app.
```shell
dokku buildpacks:clear node-js-app
```
### Using a specific buildpack version
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
By default, builders will pin their vendored buildpacks, resulting in a consistent build result for your application. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified _without_ a Git commit SHA like so:
This will use the latest commit on the `master` branch of the specified buildpack. To pin to a newer version of a buildpack, a sha may also be specified by using the form `REPOSITORY_URL#COMMIT_SHA`, where `COMMIT_SHA` is any tree-ish git object - usually a git tag.
@@ -14,8 +14,8 @@ buildpacks:set-property [--global|<app>] <key> <value> # Set or clear a buildpa
Cloud Native Buildpacks are an evolution over the Buildpacks technology provided by the Herokuish builder. See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how to clear buildpack build cache for an application.
> [!WARNING]
> This functionality uses the `pack` cli from the [Cloud Native Buildpacks](https://buildpacks.io) project to build apps. As the integration is experimental in Dokku, it is likely to change over time.
> [!NOTE]
> This functionality uses the `pack` cli from the [Cloud Native Buildpacks](https://buildpacks.io) project to build apps.
## Usage
@@ -27,7 +27,7 @@ Builds will proceed with the `pack` cli for the app from then on.
### Caveats
As this functionality is highly experimental, there are a number of caveats. Please note that not all issues are listed below.
While pack is well-supported in Dokku, there are a number of caveats. Please note that not all issues are listed below.
- Specifying specific buildpacks is not currently possible.
- A future release will add support for specifying buildpacks via the `buildpacks` plugin.
@@ -41,16 +41,7 @@ As this functionality is highly experimental, there are a number of caveats. Ple
### Detection
This builder will be auto-detected in either the following cases:
- The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
- A `project.toml` file exists in the root of the app repository.
- This file is consumed by `pack-cli` and used to describe how the app is built.
This builder will be auto-detected if a `project.toml` file exists in the root of the app repository. This file is consumed by `pack-cli` and used to describe how the app is built.
The builder can also be specified via the `builder:set` command:
Setting `$DOKKU_DOCKERFILE_CACHE_BUILD` to `true` or `false` will enable or disable Docker's image layer cache. Lastly, for more granular build control, you may also pass any `docker build` option to `docker`, by setting `$DOKKU_DOCKER_BUILD_OPTS`.
> Dokku will only select the `dockerfile` builder if both the `herokuish` and `pack` builders are not detected and a Dockerfile exists. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how that builder functions.
### Listing Buildpacks in Use
The `buildpacks:list` command can be used to show buildpacks that have been set for an app. This will omit any auto-detected buildpacks.
```shell
# running for an app with no buildpacks specified
dokku buildpacks:list node-js-app
```
```
-----> test buildpack urls
```
```shell
# running for an app with two buildpacks specified
> Please check the documentation for your particular buildpack as you may need to include configuration files (such as a Procfile) in your project root.
To add a custom buildpack, use the `buildpacks:add` command:
In some cases, it may be necessary to swap out a given buildpack. Rather than needing to re-specify each buildpack, the `buildpacks:set` command can be used to overwrite a buildpack at a given position.
By default, this will overwrite the _first_ buildpack specified. To specify an index, the `--index` flag may be used. This flag is specified starting at a 1-index value, and defaults to `1`.
### Displaying builder-herokuish reports for an app
> [!IMPORTANT]
@@ -309,24 +162,6 @@ If an application was previously deployed via Dockerfile, the following commands
dokku ports:clear node-js-app
```
### Using a specific buildpack version
> Always remember to pin your buildpack versions when using the multi-buildpacks method, or you may find deploys changing your deployed environment.
By default, Dokku uses the [gliderlabs/herokuish](https://github.com/gliderlabs/herokuish/) project, which pins all of it's vendored buildpacks. There may be occasions where the pinned version results in a broken deploy, or does not have a particular feature that is required to build your project. To use a more recent version of a given buildpack, the buildpack may be specified _without_ a Git commit SHA like so:
This will use the latest commit on the `master` branch of the specified buildpack. To pin to a newer version of a buildpack, a sha may also be specified by using the form `REPOSITORY_URL#COMMIT_SHA`, where `COMMIT_SHA` is any tree-ish git object - usually a git tag.
Certain buildpacks may time out in retrieving dependencies via `curl`. This can happen when your network connection is poor or if there is significant network congestion. You may see a message similar to `gzip: stdin: unexpected end of file` after a `curl` command.
@@ -345,3 +180,32 @@ See the [repository management documentation](/docs/advanced-usage/repository-ma
### Specifying commands via Procfile
See the [Procfile documentation](/docs/processes/process-management.md#procfile) for more information on how to specify different processes for your app.
### Listing Buildpacks in Use
See the [buildpack management documentation](/docs/processes/process-management.md#listing-buildpacks-in-use) for more information on how to list buildpacks in use.
### Adding custom buildpacks
See the [buildpack management documentation](/docs/processes/process-management.md#adding-custom-buildpacks) for more information on how to add custom buildpacks.
### Overwriting a buildpack position
See the [buildpack management documentation](/docs/processes/process-management.md#overwriting-a-buildpack-position) for more information on how to overwrite a buildpack position.
### Removing a buildpack
See the [buildpack management documentation](/docs/processes/process-management.md#removing-a-buildpack) for more information on how to remove a buildpack.
### Clearing all buildpacks
See the [buildpack management documentation](/docs/processes/process-management.md#clearing-all-buildpacks) for more information on how to clear all buildpacks.
### Using a specific buildpack version
See the [buildpack management documentation](/docs/processes/process-management.md#using-a-specific-buildpack-version) for more information on how to using a specific buildpack version
### Displaying buildpack reports for an app
See the [buildpack management documentation](/docs/processes/process-management.md#displaying-buildpack-reports-for-an-app) for more information on how to display buildpack reports for an app.
The `railpack` builder builds apps via [Railpack](https://railpack.com/), a buildpack alternative.
## Usage
### Requirements
Before using Railpacks, the following steps must be taken:
- Install the `railpack` cli: The `railpack` cli tool is not included by default with Dokku or as a dependency. It must also be installed as shown on [this page](https://railpack.com/installation).
- Create a `buildkit` builder: Railpack uses buildkit.
```shell
docker run --rm --privileged -d --name buildkit moby/buildkit
```
- Set the buildkit builder: Update the `/etc/default/dokku` file to set `BUILDKIT_HOST`:
This builder will be auto-detected in the following case:
- A `railpack.json` 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 railpack
```
### Supported languages
See the [upstream railpack documentation](https://railpack.com/) for further information on what languages and frameworks are supported.
### Build-time configuration variables
For security reasons - and as per [Docker recommendations](https://github.com/docker/docker/issues/13490) - railpack-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). All environment variables set by the `config` plugin are automatically exported within the railpack build environment, and thus `--env` only requires setting a key without a value.
The `railpack.json` is expected to be found in a specific directory, depending on the deploy approach:
- The `WORKDIR` of the Docker image for deploys resulting from `git:from-image` and `git:load-image` commands.
- The root of the source code tree for all other deploys (git push, `git:from-archive`, `git:sync`).
Sometimes it may be desirable to set a different path for a given app, e.g. when deploying from a monorepo. This can be done via the `railpackjson-path` property:
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, the build will fail.
The default value may be set by passing an empty value for the option:
The `railpackjson-path` property can also be set globally. The global default is `railpack.json`, and the global value is used when no app-specific value is set.
[Woodpecker CI](https://woodpecker-ci.org/docs/intro) can be used to automatically deploy a Dokku application via the official [dokku/ci-docker-image](https://github.com/dokku/ci-docker-image). The simplest example is as follows:
```yaml
when:
- event:push
branch:main
clone:
git:
image:woodpeckerci/plugin-git
settings:
partial:false
depth:0
steps:
- name:deploy
image:dokku/ci-docker-image
environment:
GIT_REMOTE_URL:ssh://dokku@dokku.me:22/appname
SSH_PRIVATE_KEY:
from_secret:DOKKU_ME_SSH_DEPLOY_KEY
commands:
- dokku-deploy
```
- The standard `clone` stage is replaced with one that performs a complete clone of the repository (the default is a shallow clone, which dokku would reject).
- A `GIT_REMOTE_URL` and a `SSH_PRIVATE_KEY` (with help of the `from_secret` directive) suffice to carry out a deployment.
@@ -234,6 +234,19 @@ For some sinks - such as the `http` sink - it may be useful to use special chara
dokku logs:set test vector-sink "http://?uri=https%3A//loggerservice.com%3A1234/%3Ftoken%3Dabc1234%26type%3Dvector"
```
For kubernetes, it may be necessary to use template syntax - `{{ .parent.child }}` - in the sink configuration. Naively using brackets will fail due to the Helm chart install process assuming that the template should be interpreted at Helm install time vs by Vector itself. To avoid this, use `base64enc:` values (available only for top-level properties at this time). The following example shows how to use `{{ pod }}` as a value.
```shell
# encode the value with a Helm `print` statement wrapper
encoded="$(echo'{{ print "{{ pod }}" }}'| base64)"
# the value of encoded should be: e3sgcHJpbnQgInt7IHBvZCB9fSIgfX0K
# set the value
dokku logs:set test vector-sink "http://?process=base64enc%3A${encoded}"
```
This will transform the value to it's encoded form when configuring Vector sinks for Kubernetes.
Please read the [sink documentation](https://vector.dev/docs/reference/configuration/sinks/) for your sink of choice to configure the sink as desired.
@@ -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 overridden via the `--remote` flag.
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overridden via the `--remote` flag. Must specify the `--app` flag when specified.
-`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):
@@ -99,6 +99,12 @@ To list all available remotes, run `dokku remote:list`. This is equivalent to ru
To add a remote, run `dokku remote:add $REMOTE_NAME dokku@dokku.me:$APP_NAME`, replacing `$REMOTE_NAME` with your desired remote name, the `$APP_NAME` with your desired app name and the host `dokku.me` with your Dokku host. This is equivalent to running `git remote add $REMOTE_NAME dokku@dokku.me:$APP_NAME`.
The following remote formats are supported:
-`dokku@HOSTNAME.TLD:APP_NAME`
-`ssh://dokku@HOSTNAME.TLD/APP_NAME`
-`ssh://dokku@HOSTNAME.TLD:HOST_PORT/APP_NAME`
To remove a remote, run `dokku remote:remove $REMOTE_NAME`. This is equivalent to running `git remote remove $REMOTE_NAME`.
By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote *must* be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
scheduler-k3s:annotations:set <app|--global> <property> (<value>) [--process-type PROCESS_TYPE] <--resource-type RESOURCE_TYPE>, Set or clear an annotation for a given app/process-type/resource-type combination
scheduler-k3s:autoscaling-auth:set <app|--global> <trigger> [<--metadata key=value>...], Set or clear a scheduler-k3s autoscaling keda trigger authentication resource for an app
scheduler-k3s:autoscaling-auth:report <app|--global> [--format stdout|json] [--include-metadata] # Displays a scheduler-k3s autoscaling auth report for an app
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: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: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:profiles:add <profile> [--role ROLE] [--insecure-allow-unknown-hosts] [--taint-scheduling] [--kubelet-args KUBELET_ARGS] Adds a node profile to the k3s cluster
scheduler-k3s:profiles:list [--format json|stdout] # Lists all node profiles in the k3s cluster
scheduler-k3s:profiles:remove <profile> # Removes a node profile from the k3s cluster
scheduler-k3s:report [<app>] [<flag>] # Displays a scheduler-k3s report for one or more apps
scheduler-k3s:set [<app>|--global] <key> (<value>) # Set or clear a scheduler-k3s property for an app or the scheduler
scheduler-k3s:show-kubeconfig # Displays the kubeconfig for remote usage
Nodes that run app workloads can be added via the `scheduler-k3s:cluster-add` command. This will ssh onto the specified server, install k3s, and join it to the current Dokku node in worker mode. Workers are typically used to run app workloads.
Nodes that run app workloads can be added via the `scheduler-k3s:cluster:add` command. This will ssh onto the specified server, install k3s, and join it to the current Dokku node in worker mode. Workers are typically used to run app workloads.
Per-node kubelet flags can be supplied by passing `--kubelet-args` with a comma-separated `key=value` list. This is useful for tuning scheduler capacity or enforcing cluster-wide defaults at the node level.
Multiple kubelet arguments can be specified in the same call by separating them with commas. The following example enables IPv4 forwarding while also increasing the pod density on the worker.
By default, Dokku will attempt to auto-detect the IP address of the Dokku server for the remote server to connect to. In cases where the auto-detected IP address is incorrect, an override may be specified via the `--server-ip` flag:
Server nodes are typically used to replicate the cluster state, and it is recommended to have an odd number of nodes spread across several availability zones (datacenters in close proximity within a region). This allows for higher availability in the event of a cluster failure. Server nodes run control-plane services such as the traefik load balancer and the etcd backing store.
Server nodes can also be added with the `scheduler-k3s:cluster-add` command by specifying `--role server`. This will ssh onto the specified server, install k3s, and join it to the current Dokku node in server mode.
Server nodes can also be added with the `scheduler-k3s:cluster:add` command by specifying `--role server`. This will ssh onto the specified server, install k3s, and join it to the current Dokku node in server mode.
```shell
dokku scheduler-k3s:cluster-add --role server ssh://root@server-1.example.com
dokku scheduler-k3s:cluster:add --role server ssh://root@server-1.example.com
```
Server nodes allow any workloads to be scheduled on them by default, in addition to the control-plane, etcd, and the scheduler itself. To avoid app workloads being scheduled on your control-plane, use the `--taint-scheduling` flag:
```shell
dokku scheduler-k3s:cluster-add --role server --taint-scheduling ssh://root@server-1.example.com
dokku scheduler-k3s:cluster:add --role server --taint-scheduling ssh://root@server-1.example.com
```
If the server isn't in the `known_hosts` file, the connection will fail. This can be bypassed by setting the `--insecure-allow-unknown-hosts` flag:
```shell
dokku scheduler-k3s:cluster-add --role server --insecure-allow-unknown-hosts ssh://root@server-1.example.com
dokku scheduler-k3s:cluster:add --role server --insecure-allow-unknown-hosts ssh://root@server-1.example.com
```
By default, Dokku will attempt to auto-detect the IP address of the Dokku server for the remote server to connect to. In cases where the auto-detected IP address is incorrect, an override may be specified via the `--server-ip` flag:
```shell
dokku scheduler-k3s:cluster-add --role server --server-ip 192.168.20.15 ssh://root@server-1.example.com
dokku scheduler-k3s:cluster:add --role server --server-ip 192.168.20.15 ssh://root@server-1.example.com
```
#### Changing the network interface
@@ -134,6 +153,48 @@ When attaching an worker or server node, the K3s plugin will look at the IP asso
Node profiles capture repeatable `scheduler-k3s:cluster:add` options so you can join multiple nodes with identical settings. A profile name can be specified for the `scheduler-k3s:cluster:add` command via the `--profile <name>` flag. Any flags passed directly to `scheduler-k3s:cluster:add` override the stored values for that run.
#### Listing profiles
Display stored profiles to understand which roles and behaviors will be used.
```shell
dokku scheduler-k3s:profiles:list
```
```
name role
awesome-profile worker
```
This command also takes an optional `--format` flag to specify a format for the output. Options include `json` and `stdout`
#### Adding profiles
Create or update a profile that defines how new nodes should be prepared before joining the cluster.
Profile names must be alphanumeric, may include internal dashes, cannot start/end with a dash, and must be ≤32 characters. Other than the `--server-ip` flag, all flags used for `scheduler-k3s:cluster:add` are valid for the `scheduler-k3s:profiles:add` command.
#### scheduler-k3s:profiles:remove
Delete a profile once it’s no longer required.
```shell
dokku scheduler-k3s:profiles:remove edge-workers
```
Removal only deletes the stored definition; nodes that already joined the cluster keep their existing configuration.
### Changing deployment settings
The k3s plugin provides a number of settings that can be used to managed deployments on a per-app basis. The following table outlines ones not covered elsewhere:
@@ -141,6 +202,7 @@ The k3s plugin provides a number of settings that can be used to managed deploym
@@ -170,6 +232,27 @@ The global default value may be set by passing an empty value for the option.
dokku scheduler-k3s:set --global deploy-timeout
```
### Exposing services on the network
Dokku will automatically expose the `web` process as a Kubernetes Service, with all others being treated as background processes. In some cases, it may be useful to have other processes exposed as Kubernetes Service objects so as to segregate internal http endpoints from public http endpoints. This can be done by modifying the `app.json` Formation entry for your process type.
```json
{
"formation":{
"internal-web":{
"service":{
"exposed":true
}
}
}
}
```
In the above example, the `internal-web` process is exposed as a service. The `PORT` variable for the process will be set to `5000`, and a kubernetes `Service` object will be created pointing at your processes.
> [!NOTE]
> It is not possible to modify the port mapping, nor is it possible to assign domains or SSL to a non-web process.
### SSL Certificates
#### Enabling letsencrypt integration
@@ -200,7 +283,7 @@ The default value may be set by passing an empty value for the option:
Dokku supports integration with [Kustomize](https://kustomize.io/) to further customize the generated helm charts for app deployments. For example, a `config/kustomize/kustomization.yaml` file with the following contents will override the scale for each process deployed to `3`:
```yaml
apiVersion:kustomize.config.k8s.io/v1beta1
kind:Kustomization
resources:
- rendered.yaml
patches:
- patch:|-
- op: replace
path: /spec/replicas
value: 3
target:
group:apps
version:v1
kind:Deployment
```
When using Kustomize with Dokku, all Kustomize-files _must_ be placed in the `config/kustomize` folder, with a `kustomization.yaml` file being the entrypoint to Kustomize. Dokku will render the helm chart to a `rendered.yaml` file, and then execute Kustomize with the `config/kustomize` folder as the context.
See the [Kustomize](https://kustomize.io/) website for more details on how to use Kustomize.
> 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:
```shell
@@ -545,6 +662,11 @@ This plugin implements various functionality through `plugn` triggers to integra
-`apps:clone`
-`apps:destroy`
-`apps:rename`
-`docker-options`:
- The following docker options are translated into their kubernetes equivalents:
-`--cap-add`
-`--cap-drop`
-`--privileged`
-`cron`
-`enter`
-`deploy`
@@ -588,6 +710,7 @@ Next, run the `scheduler-k3s:ensure-charts` command with the `vector` chart to f
```shell
dokku scheduler-k3s:ensure-charts --charts vector
```
Please see the [vector logs documentation](/docs/deployment/logs.md#configuring-a-log-sink) for more information on specifying vector sinks.
You can set the `stop-timeout-seconds` property on the `ps` plugin to change this value (default: `30`). See the [process management documentation](/docs/processes/process-management.md#changing-process-management-settings) for more information.
## 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.
The following settings may also be specified in the `app.json` file, though are available as environment variables in order to ease application reuse.
@@ -119,6 +119,21 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `app-json-is-valid`
- Description: Checks to see if the provided app.json file is valid
- Invoked by: Appjson extraction during deployment
- Arguments: `$APP $APP_JSON_PATH`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-maybe-create`
- Description: Creates an app (gated by whether this is globally enabled or not)
@@ -567,7 +582,7 @@ APP="$1"; PROPERTY="$2"
### `cron-entries`
- Description: Allows injecting cron entries into the written out scheduled cron task list. Each entry is newline delimited, and individual entries come in the form `$SCHEDULE;$FULL_COMMAND;$ARBITRARY_DATA`. Individual implementations of cron writing can decide whether and how to include these cron entries. The `ARBITRARY_DATA` includes the log file path for the basic `docker-local` cron implementation.
- Description: Allows injecting cron tasks into the written out scheduled cron task list. Each entry is newline delimited, and individual tasks come in the form `$SCHEDULE;$FULL_COMMAND;$ARBITRARY_DATA`. Individual implementations of cron writing can decide whether and how to include these cron tasks. The `ARBITRARY_DATA` includes the log file path for the basic `docker-local` cron implementation.
- Invoked by:
- Arguments: `$DOKKU_SCHEDULER`
- Example:
@@ -583,22 +598,6 @@ DOKKU_SCHEDULER="$1"
# TODO
```
### `cron-write`
- Description: Force triggers writing out cron entries
- Description: Allows you to run commands once the domain for an app has been updated. It also sends in the command that has been used. This can be "add", "clear" or "remove". The third argument will be the optional list of domains
@@ -13,7 +13,7 @@ All pull requests have tests run against them on [GitHub Actions](https://github
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 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).
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 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.
The alternative is to build a custom docker image via a custom Dockerfile. This Dockerfile can run any `plugin:install` command, though the `install` trigger must be skipped via the `--skip-install-trigger`. 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.18
RUN dokku plugin:install https://github.com/dokku/dokku-postgres.git postgres
RUN dokku plugin:install https://github.com/dokku/dokku-redis.git redis
FROMdokku/dokku:0.37.2
RUN dokku plugin:install https://github.com/dokku/dokku-postgres.git --skip-install-trigger
RUN dokku plugin:install https://github.com/dokku/dokku-redis.git --skip-install-trigger
- A server with one of the following architectures
-AMD64 (alternatively known as `x86_64`), commonly used for Intel cloud servers
- 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-1-gb-of-memory).
-Operating Systems: [Ubuntu 22.04/24.04](https://www.ubuntu.com/download) or [Debian 11+ x64](https://www.debian.org/distrib/)
- Supported Architectures: `AMD64` (`x86_64`) and `arm64` (`armv8`)
- Minimum Memory:
- Docker Scheduler: 1GB of system memory, or [add swap memory](/docs/getting-started/advanced-installation.md#vms-with-less-than-1-gb-of-memory)
-K3s Scheduler: 2GB of system memory on every node in the cluster
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.
@@ -37,8 +31,8 @@ To install the latest stable version of Dokku, you can run the following shell c
Dokku provides integration with the [Caddy](https://caddyserver.com/) proxy service by utilizing the Docker label-based integration implemented by Caddy.
Dokku provides integration with the [Caddy](https://caddyserver.com/) proxy service by utilizing the Docker label-based integration implemented by [Caddy Docker Proxy](https://github.com/lucaslorentz/caddy-docker-proxy).
```
caddy:report [<app>] [<flag>] # Displays a caddy report for one or more apps
After modifying, the Caddy container will need to be restarted.
### Label Management
The Caddy plugin allows you to add custom container labels to apps. These labels are injected into containers during deployment and can be used to configure Caddy behavior beyond what the plugin provides by default.
Refer to the upstream [caddy-docker-proxy](https://github.com/lucaslorentz/caddy-docker-proxy) documentation for more information on what labels are available.
#### Adding a label
To add a custom container label to an app, use the `caddy:labels:add` command:
```shell
dokku caddy:labels:add node-js-app caddy.directive value
```
This will add the label `caddy.directive=value` to the app's containers. After adding a label, you will need to rebuild or redeploy the app for the label to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Removing a label
To remove a custom container label from an app, use the `caddy:labels:remove` command:
This will remove the specified label from the app. After removing a label, you will need to rebuild or redeploy the app for the change to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Showing labels
To view all custom container labels for an app, use the `caddy:labels:show` command:
```shell
dokku caddy:labels:show node-js-app
```
To view a specific label value, provide the label name:
The caddy plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
The caddy plugin only supports automatic ssl certificates from its letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
After modifying, the Haproxy container will need to be restarted.
### Label Management
The Haproxy plugin allows you to add custom container labels to apps. These labels are injected into containers during deployment and can be used to configure Haproxy behavior beyond what the plugin provides by default.
Refer to the upstream [EasyHaproxy](https://github.com/byjg/docker-easy-haproxy) documentation for more information on what labels are available.
#### Adding a label
To add a custom container label to an app, use the `haproxy:labels:add` command:
```shell
dokku haproxy:labels:add node-js-app haproxy.directive value
```
This will add the label `haproxy.directive=value` to the app's containers. After adding a label, you will need to rebuild or redeploy the app for the label to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Removing a label
To remove a custom container label from an app, use the `haproxy:labels:remove` command:
This will remove the specified label from the app. After removing a label, you will need to rebuild or redeploy the app for the change to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Showing labels
To view all custom container labels for an app, use the `haproxy:labels:show` command:
```shell
dokku haproxy:labels:show node-js-app
```
To view a specific label value, provide the label name:
The haproxy plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
@@ -332,6 +332,7 @@ Changing these value globally or on a per-app basis will require rebuilding the
| 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 |
| nginx-service-command | | string | Full path to an executable script or binary to invoke instead of the system's init process when interacting with nginx |
| 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 |
@@ -124,6 +124,54 @@ The following folders within an app repository may have `*.conf` files that will
-`openresty/http-includes/`: Injected in the `server` block serving http(s) requests for the app.
-`openresty/http-location-includes/`: Injected in the `location` block that proxies to the app in the app's respective `server` block.
### Label Management
The OpenResty plugin allows you to add custom container labels to apps. These labels are injected into containers during deployment and can be used to configure OpenResty behavior beyond what the plugin provides by default.
Refer to the upstream [openresty-docker-proxy](https://github.com/dokku/openresty-docker-proxy) documentation for more information on what labels are available.
#### Adding a label
To add a custom container label to an app, use the `openresty:labels:add` command:
```shell
dokku openresty:labels:add node-js-app openresty.directive value
```
This will add the label `openresty.directive=value` to the app's containers. After adding a label, you will need to rebuild or redeploy the app for the label to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Removing a label
To remove a custom container label from an app, use the `openresty:labels:remove` command:
This will remove the specified label from the app. After removing a label, you will need to rebuild or redeploy the app for the change to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Showing labels
To view all custom container labels for an app, use the `openresty:labels:show` command:
```shell
dokku openresty:labels:show node-js-app
```
To view a specific label value, provide the label name:
The OpenResty plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
After modifying, the Traefik container will need to be restarted.
### Label Management
The Traefik plugin allows you to add custom container labels to apps. These labels are injected into containers during deployment and can be used to configure Traefik behavior beyond what the plugin provides by default.
Refer to the upstream [Traefik](https://doc.traefik.io/traefik/) documentation for more information on what labels are available.
#### Adding a label
To add a custom container label to an app, use the `traefik:labels:add` command:
```shell
dokku traefik:labels:add node-js-app traefik.directive value
```
This will add the label `traefik.directive=value` to the app's containers. After adding a label, you will need to rebuild or redeploy the app for the label to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Removing a label
To remove a custom container label from an app, use the `traefik:labels:remove` command:
This will remove the specified label from the app. After removing a label, you will need to rebuild or redeploy the app for the change to be applied to running containers.
```shell
dokku ps:rebuild node-js-app
```
#### Showing labels
To view all custom container labels for an app, use the `traefik:labels:show` command:
```shell
dokku traefik:labels:show node-js-app
```
To view a specific label value, provide the label name:
The traefik plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the `certs` plugin are ignored.
run [-e|--env KEY=VALUE] [--no-tty] <app> <cmd> # Run a command in a new container using the current app image
run:detached [-e|-env KEY=VALUE] [--force-tty] <app> <cmd> # Run a command in a new detached container using the current app image
run [-e|--env KEY=VALUE] [--no-tty] [--ttl-seconds SECONDS] <app> <cmd> # Run a command in a new container using the current app image
run:detached [-e|-env KEY=VALUE] [--force-tty] [--ttl-seconds SECONDS] <app> <cmd> # Run a command in a new detached container using the current app image
run:list [--format json|stdout] [<app>] # List all run containers for an app
run:logs <app|--container CONTAINER> [-h] [-t] [-n num] [-q] # Display recent log output for run containers
run:stop <app|--container CONTAINER> # Stops all run containers for an app or a specified run container
One off containers are removed at the end of process execution.
In addition, one-off containers also run for a max of 24 hours (86400 seconds) by default, after which they are reaped. This can be changed by setting the `--ttl-seconds` argument:
```shell
# runs for 10 minutes
dokku run --ttl-seconds 600 node-js-app npm run mytask
```
One-off containers that exceed their runtime are reaped every 5 minutes, so the ttl-seconds is an approximation and your app may end up running for up to 5 minutes longer than expected.
#### Running Procfile commands
The `run` command can also be used to run a command defined in the app `Procfile`:
The `ps` plugin provides a number of settings that can be used to managed deployments on a per-app basis. The following table outlines ones not covered elsewhere:
| `stop-timeout` | 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. | `30` |
All settings can be set via the `ps:set` command. Using `stop-timeout` as an example:
```shell
dokku ps:set node-js-app stop-timeout 60
```
The default value may be set by passing an empty value for the option in question:
```shell
dokku ps:set node-js-app stop-timeout
```
Properties can also be set globally. If not set for an app, the global value will apply.
```shell
dokku ps:set --global stop-timeout 60
```
The global default value may be set by passing an empty value for the option.
cron:list <app> [--format json|stdout] # List scheduled cron tasks for an app
cron:report [<app>] [<flag>] # Display report about an app
cron:resume <app> <cron_id> # Resume a cron task
cron:run <app> <cron_id> [--detach] # Run a cron task on the fly
cron:set [--global|<app>] <key> <value> # Set or clear a cron property for an app
cron:suspend <app> <cron_id> # Suspend a cron task
```
## Usage
@@ -31,12 +33,17 @@ The `app.json` file for a given app can define a special `cron` key that contain
}
```
A cron entry takes the following properties:
A cron task takes the following properties:
-`command`: A command to be run within the built app image. Specified commands can also be `Procfile` entries.
-`maintenance`: A boolean value that decides whether the cron task is in maintenance and therefore executable or not.
-`schedule`: A [cron-compatible](https://en.wikipedia.org/wiki/Cron#Overview) scheduling definition upon which to run the command. Seconds are generally not supported.
-`concurrency_policy`: A string (default: `allow`), that controls whether the cron task can be run concurrently with another invocation of itself. Valid options are `allow` (allow concurrency), `forbid` (exit the new cron task if there is an existing one), `replace` (delete any existing cron task and start the new one).
Zero or more cron commands can be specified per app. Cron entries are validated after the build artifact is created but before the app is deployed, and the cron schedule is updated during the post-deploy phase.
Zero or more cron tasks can be specified per app. Cron tasks are validated after the build artifact is created but before the app is deployed, and the cron schedule is updated during the post-deploy phase.
Cron tasks can run for a maximum of 24 hours via the docker-local scheduler, after which they are reaped from the system.
See the [app.json location documentation](/docs/advanced-usage/deployment-tasks.md#changing-the-appjson-location) for more information on where to place your `app.json` file.
@@ -53,39 +60,39 @@ When running scheduled cron tasks, there are a few items to be aware of:
- 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
### Changing cron management settings
Users can specify a value for `MAILFROM` via the global `mailfrom` cron property by using the `cron:set` command.
The `cron` plugin provides a number of settings that can be used to managed deployments on a per-app basis. The following table outlines ones not covered elsewhere:
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.
The default value may be set by passing an empty value for the option in question:
```shell
dokku cron:set --global mailfrom
dokku cron:set node-js-app maintenance
```
#### 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.
If a property can be set globally - such as `mailto`, use the `--global` flag. If not set for an app, the global value will apply if it exists.
Cron tasks can be suspended to temporarily prevent them from running, and later resumed to re-enable them. This is useful for maintenance or debugging purposes.
To suspend a specific cron task, use the `cron:suspend` command with the app name and cron ID:
A suspended task will not execute according to its schedule. You can verify a task is suspended by checking the `Maintenance` column in the `cron:list` output, which will show `true (task)` for suspended tasks.
To resume a suspended cron task, use the `cron:resume` command:
Once resumed, the task will execute according to its schedule again. The cron ID can be retrieved from the `cron:list` output.
#### Executing a cron task on the fly
Cron tasks can be invoked via the `cron:run` command. This command takes an `app` argument and a `cron id` (retrievable from `cron:list` output).
@@ -207,7 +245,7 @@ For tasks that will properly resume, you _should_ use the above method, as runni
Regularly scheduled tasks can be a bit of a pain with Dokku. The following are general recommendations to follow to help ensure successful task runs.
- Use the `dokku` user in your cron entry.
- Use the `dokku` user in your cron task.
- If you do not, the `dokku` binary will attempt to execute with `sudo`, and your cron run with fail with `sudo: no tty present and no askpass program specified`.
- Add a `MAILTO` environment variable to ship cron emails to yourself.
- Add a `PATH` environment variable or specify the full path to binaries on the host.
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.
