# History
## 0.37.3
Install/update via the bootstrap script:
```shell
wget -NP . https://dokku.com/install/v0.37.3/bootstrap.sh
sudo DOKKU_TAG=v0.37.3 bash bootstrap.sh
```
### Bug Fixes
- #8199: @josegonzalez Pass global build args as array when building nixpacks apps
- #8236: @josegonzalez Ensure the /etc/docker exists when interacting with it via postinst
### Documentation
- #8229: @kleutzinger Fix command syntax for removing docker options
- #8219: @deanmarano Add deanmarano to community plugins list
- #8205: @deanmarano Add DNS plugin to community plugins list
### Tests
- #8246: @josegonzalez Add tests to prove that Procfile tasks all work for every builder
### Dependencies
- #8243: @dependabot[bot] chore(deps): bump k8s.io/kubectl from 0.34.2 to 0.35.0 in /plugins/scheduler-k3s
- #8245: @dependabot[bot] chore(deps): bump github.com/go-resty/resty/v2 from 2.17.0 to 2.17.1 in /plugins/scheduler-k3s
- #8244: @dependabot[bot] chore(deps): bump k8s.io/kubernetes from 1.34.2 to 1.35.0 in /plugins/scheduler-k3s
- #8233: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.38.2 to 1.38.3 in /plugins/common
- #8241: @dependabot[bot] chore(deps): bump github.com/traefik/traefik/v2 from 2.11.32 to 2.11.33 in /plugins/scheduler-k3s
- #8240: @dependabot[bot] chore(deps): bump github.com/cert-manager/cert-manager from 1.19.1 to 1.19.2 in /plugins/scheduler-k3s
- #8239: @dependabot[bot] chore(deps): bump pyparsing from 3.2.5 to 3.3.1 in /docs/_build
- #8238: @dependabot[bot] chore(deps): bump google.golang.org/grpc from 1.77.0 to 1.78.0 in /tests/apps/gogrpc
- #8237: @dependabot[bot] chore(deps): bump github.com/kedacore/keda/v2 from 2.18.2 to 2.18.3 in /plugins/scheduler-k3s
- #8235: @dependabot[bot] chore(deps): bump helm.sh/helm/v3 from 3.19.2 to 3.19.4 in /plugins/scheduler-k3s
- #8232: @dependabot[bot] chore(deps): bump importlib-metadata from 8.7.0 to 8.7.1 in /docs/_build
- #8234: @dependabot[bot] chore(deps): bump k8s.io/client-go from 0.34.2 to 0.35.0 in /plugins/scheduler-k3s
- #8231: @dependabot[bot] chore(deps): bump github.com/expr-lang/expr from 1.17.6 to 1.17.7 in /plugins/scheduler-k3s
- #8208: @dependabot[bot] chore(deps): bump golang.org/x/crypto from 0.45.0 to 0.46.0 in /plugins/common
- #8201: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.18.0 to 0.19.0 in /plugins/common
- #8214: @dependabot[bot] chore(deps): bump google.golang.org/protobuf from 1.36.10 to 1.36.11 in /tests/apps/gogrpc
- #8216: @dependabot[bot] chore(deps): bump actions/download-artifact from 6 to 7
- #8217: @dependabot[bot] chore(deps): bump actions/upload-artifact from 5 to 6
- #8228: @dependabot[bot] chore(deps): bump soupsieve from 2.8 to 2.8.1 in /docs/_build
- #8226: @dependabot[bot] chore(deps): bump ruby from 3.4.7 to 3.4.8 in /tests/apps/dockerfile-entrypoint
- #8227: @dependabot[bot] chore(deps): bump mkdocs-material from 9.7.0 to 9.7.1 in /docs/_build
- #8224: @dependabot[bot] chore(deps): bump traefik from 3.6.4 to 3.6.5 in /plugins/traefik-vhosts
- #8225: @dependabot[bot] chore(deps): bump timberio/vector from 0.51.1-debian to 0.52.0-debian in /plugins/logs
- #8220: @dependabot[bot] chore(deps): bump python from 3.14.1-bookworm to 3.14.2-bookworm in /tests/apps/dockerfile-release
- #8221: @dependabot[bot] chore(deps): bump python from 3.14.1-alpine to 3.14.2-alpine in /docs/_build
- #8218: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.19 to 10.19.1 in /docs/_build
- #8215: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.18 to 10.19 in /docs/_build
- #8209: @dependabot[bot] chore(deps): bump github.com/onsi/gomega from 1.38.2 to 1.38.3 in /plugins/config
- #8210: @dependabot[bot] chore(deps): bump github.com/kedacore/keda/v2 from 2.18.1 to 2.18.2 in /plugins/scheduler-k3s
- #8211: @dependabot[bot] chore(deps): bump github.com/go-openapi/jsonpointer from 0.22.3 to 0.22.4 in /plugins/scheduler-k3s
- #8200: @dependabot[bot] chore(deps): bump pymdown-extensions from 10.17.2 to 10.18 in /docs/_build
- #8202: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.18.0 to 0.19.0 in /plugins/scheduler-docker-local
- #8203: @dependabot[bot] chore(deps): bump traefik from 3.6.2 to 3.6.4 in /plugins/traefik-vhosts
- #8204: @dependabot[bot] chore(deps): bump golang.org/x/sync from 0.18.0 to 0.19.0 in /plugins/scheduler-k3s
# 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
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.
To remove docker options from an app, use the `docker-options:remove` command. This takes an app name, a comma-separated list of phases, and the docker-option to remove.
```shell
dokku docker-options:remove node-js-app run ""--ulimit nofile=12"
dokku docker-options:remove node-js-app run "--ulimit nofile=12"
```
Multiple phases can be specified by using a comma when specifying phases:
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.36.2 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.
- 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.
config:export (<app>|--global) [--envfile] Export a global or app environment
config:export (<app>|--global) [--format <format>] Export a global or app environment
config:get (<app>|--global) KEY Display a global or app-specific config value
config:keys (<app>|--global) [--merged] Show keys set in environment
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
@@ -110,7 +110,6 @@ The following config variables have special meanings and can be set in a variety
| `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_APP_AUTOCREATION` | none | `dokku config:set` | Disables automatic creation of a non-existent app on deploy. |
> 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.
@@ -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:
@@ -171,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
@@ -201,7 +283,7 @@ The default value may be set by passing an empty value for the option:
- 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.
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.36.2
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.3
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.
### Changing the label key for the app
### Label Management
The default label key for the app is `caddy`. This can be changed by setting the `label-key` property:
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:set node-js-app label-key caddy_0
dokku caddy:labels:add node-js-app caddy.directive value
```
This will update the app's label key to `caddy_0`. The label key is used to identify the app in the Caddy configuration. If you change the label key, you will need to restart or rebuild the app to apply the updates.
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.
@@ -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`:
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.
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.
trap "rm -rf '$TMP_WORK_DIR' >/dev/null" RETURN INT TERM EXIT
local DOCKER_BUILD_LABEL_ARGS="--label=org.label-schema.schema-version=1.0--label=org.label-schema.vendor=dokku--label=com.dokku.app-name=$APP --label=com.dokku.image-stage=release --label=dokku"
local DOCKER_BUILD_LABEL_ARGS=("--label=org.label-schema.schema-version=1.0" "--label=org.label-schema.vendor=dokku" "--label=com.dokku.image-stage=release" "--label=com.dokku.builder-type=lambda" "--label=com.dokku.app-name=$APP" "--label=dokku")
if ! suppress_output "$DOCKER_BIN" image build "${DOCKER_BUILD_LABEL_ARGS[@]}" $DOKKU_GLOBAL_BUILD_ARGS -f "$PLUGIN_AVAILABLE_PATH/builder-lambda/dockerfiles/builder-release.Dockerfile" --build-arg APP_IMAGE="$IMAGE" -t "$IMAGE" "$TMP_WORK_DIR"; then
dokku_log_warn "Failure injecting docker labels on image"
trap "rm -rf '$TMP_WORK_DIR' >/dev/null" RETURN INT TERM EXIT
local DOCKER_BUILD_LABEL_ARGS="--label=org.label-schema.schema-version=1.0--label=org.label-schema.vendor=dokku--label=com.dokku.app-name=$APP --label=com.dokku.image-stage=release --label=dokku"
local DOCKER_BUILD_LABEL_ARGS=("--label=org.label-schema.schema-version=1.0" "--label=org.label-schema.vendor=dokku" "--label=com.dokku.image-stage=release" "--label=com.dokku.builder-type=nixpacks" "--label=com.dokku.app-name=$APP" "--label=dokku")
if ! suppress_output "$DOCKER_BIN" image build "${DOCKER_BUILD_LABEL_ARGS[@]}" $DOKKU_GLOBAL_BUILD_ARGS -f "$PLUGIN_AVAILABLE_PATH/builder-nixpacks/dockerfiles/builder-release.Dockerfile" --build-arg APP_IMAGE="$IMAGE" -t "$IMAGE" "$TMP_WORK_DIR"; then
dokku_log_warn "Failure injecting docker labels on image"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
