# History
## 0.27.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.7/bootstrap.sh
sudo DOKKU_TAG=v0.27.7 bash bootstrap.sh
```
### Bug Fixes
- #5238: @josegonzalez Respect dokku system user/group when setting storage permissions on installation
### New Features
- #5239: @josegonzalez Add builder-type and image-stage labels to all images
### Documentation
- #5241: @josegonzalez Clarify where logs are pulled from and general log shipping stance
- #5237: @josegonzalez Fix builder-pack:set command example
### Other
- #5235: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 220 to 221 in /tests/apps/php
While it is unfortunate that we don't store logs locally, doing so is actually a fairly difficult ask. Rather than pretending the problem doesn't exist, we'll clarify how logs are currently fetched, as well as point users to integrations/tools that may make their lives easier.
Refs #5234
# History
## 0.27.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.6/bootstrap.sh
sudo DOKKU_TAG=v0.27.6 bash bootstrap.sh
```
### Bug Fixes
- #5225: @josegonzalez Use original app name when setting include_labels for vector source
- #5228: @josegonzalez Always respect app.json formations in scale settings
- #5201: @josegonzalez Use pack as default builder for arm64 servers
### Documentation
- #5230: @josegonzalez Clarify usage of build args to set environment variables for Dockerfile deploys
- #5208: @asokoloski-m Fix typo in dockerfile builder docs
- #5206: @AxelTheGerman Added dokku-litestream to list of community plugins
### Other
- #5218: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 219 to 220 in /tests/apps/php
- #5222: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.10 to 11.0.11 in /tests/apps/java
- #5224: @josegonzalez Document that the community registry plugin should be uninstalled before upgrading past 0.24.x
- #5220: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.9 to 11.0.10 in /tests/apps/java
- #5212: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 218 to 219 in /tests/apps/php
- #5210: @dependabot[bot] chore(deps): bump monolog/monolog from 1.27.0 to 1.27.1 in /tests/apps/php
- #5204: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 217 to 218 in /tests/apps/php
I recently created a plugin for SQLite replication via Litestream to S3. Been using it myself in production for a couple of weeks and was able to successfully restore a backed up DB so I guess it's ready for people to try and be added to this list.
Herokuish is not and will never be supported on arm servers, so attempting to use it will only fail builds.
Also fail when trying to default to herokuish on armhf instances. We can't default to pack as it's just not built for armhf/arm (only arm64).
Closes#5113
# History
## 0.27.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.5/bootstrap.sh
sudo DOKKU_TAG=v0.27.5 bash bootstrap.sh
```
### Bug Fixes
- #5183: @josegonzalez Filter apps when verifying app names
- #5199: @josegonzalez Revert "fix: Vector fails to start container due to --watch-config flag"
- #5197: @holamendi fix: Vector fails to start container due to --watch-config flag
- #5192: @josegonzalez Confirm installation of universe packages when installing on ubuntu
- #5193: @josegonzalez Force-set correct permissions on env files
- #5181: @josegonzalez Ensure we default SSH_NAME to NAME when filtering apps
### New Features
- #5196: @josegonzalez Disable herokuish usage on both armhf and arm64 platforms
- #5194: @josegonzalez Upgrade base Dockerfile image to phusion/baseimage:focal-1.2.0
### Other
- #5200: @dependabot[bot] chore(deps): bump rack from 2.2.3 to 2.2.3.1 in /tests/apps/ruby
- #5198: @dependabot[bot] chore(deps): bump grunt from 1.5.2 to 1.5.3 in /tests/apps/multi
- #5187: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 216 to 217 in /tests/apps/php
This MR splits out the logic such that there is now a binary that handles function based calls without validating the app name. We should only every check the app name for the subcommands and not internally. Internal calls should have their arguments taken at face value.
We will not provide support for herokuish on either as herokuish is meant to be Heroku-compatible, and the Heroku stack does not support arm. Use 'pack' or Dockerfiles for app building instead.
If an env file is written as a root user - for example, during plugin install - the permissions on the file may change to root. This forces those permissions back to what they should be so that the dokku user can edit the files later on.
Closes#5190
Some things must pull *all* apps vs filtered apps (mostly things that write out config files or install triggers). Using an unflitered list is best.
Also, we default to filtering, which should be what most usage needs.
# History
## 0.27.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.2/bootstrap.sh
sudo DOKKU_TAG=v0.27.2 bash bootstrap.sh
```
### Bug Fixes
- #5166: @josegonzalez Ensure permissions for global VHOST file are set to the dokku user on install
- #5141: @josegonzalez fix: set correct version on scheduler plugin
- #5069: @josegonzalez Do not start intermediate container when calling dokku run after a failed build
### New Features
- #5168: @josegonzalez Add support for Ubuntu 22.04
- #5125: @abulava Start the vector logging container after Docker daemon restarts
- #5117: @josegonzalez Upgrade to golang 1.17.9
### Documentation
- #5167: @scottpashley Update client documentation to remove reference to unmaintained python client
### Other
- #5120: @dependabot[bot] chore(deps): bump github/codeql-action from 1 to 2
- #5145: @dependabot[bot] chore(deps): bump jinja2 from 3.1.1 to 3.1.2 in /tests/apps/python-flask
- #5157: @dependabot[bot] chore(deps): bump luizm/action-sh-checker from 0.3.0 to 0.4.0
- #5160: @dependabot[bot] chore(deps): bump docker/setup-buildx-action from 1 to 2
- #5161: @dependabot[bot] chore(deps): bump docker/login-action from 1 to 2
- #5162: @dependabot[bot] chore(deps): bump docker/setup-qemu-action from 1 to 2
- #5153: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/config
- #5152: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express-noappjson
- #5151: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express-noprocfile
- #5150: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/nodejs-express
- #5154: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/gitsubmodules
- #5155: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/.websocket.disabled
- #5163: @dependabot[bot] chore(deps): bump minimist from 1.2.5 to 1.2.6 in /tests/apps/multi
- #5149: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-dokku-scale
- #5148: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-procfile-bad
- #5147: @dependabot[bot] chore(deps): bump express from 4.17.3 to 4.18.1 in /tests/apps/dockerfile-procfile
- #5144: @dependabot[bot] chore(deps): bump flask from 2.1.1 to 2.1.2 in /tests/apps/python-flask
- #5143: @dependabot[bot] chore(deps): bump werkzeug from 2.1.1 to 2.1.2 in /tests/apps/python-flask
- #5142: @dependabot[bot] chore(deps): bump flask from 2.1.1 to 2.1.2 in /tests/apps/multi
- #5137: @dependabot[bot] chore(deps): bump grunt from 1.4.1 to 1.5.2 in /tests/apps/multi
- #5119: @dependabot[bot] chore(deps): bump socket.io from 4.4.1 to 4.5.0 in /tests/apps/.websocket.disabled
# History
## 0.27.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.1/bootstrap.sh
sudo DOKKU_TAG=v0.27.1 bash bootstrap.sh
```
### Bug Fixes
- #5095: @josegonzalez Ensure we properly clone and rename common properties
- #5094: @josegonzalez Handle case when apps:clone is run in a directory the dokku user does not have access to
- #5093: @josegonzalez Fix deploy branch setting
- #5068: @josegonzalez Properly set cron-id from flag
### New Features
- #5092: @josegonzalez Warn and exit non-zero when attempting to rebuild from a non-existent branch
- #5103: @naveensrinivasan Included githubactions in the dependabot config
### Documentation
- #5090: @josegonzalez Clarify the exact command that is run once a day by cron tasks
- #5085: @josegonzalez Use issue template form functionality on github
- #5076: @stamp-cmd Lint Markdown, Remove unused links
- #5070: @josegonzalez Add discord as support channel
### Other
- #5107: @dependabot[bot] chore(deps): bump actions/checkout from 2 to 3
- #5105: @dependabot[bot] chore(deps): bump ibiqlik/action-yamllint from 3.0.4 to 3.1
- #5109: @dependabot[bot] chore(deps): bump actions/upload-artifact from 2 to 3
- #5108: @dependabot[bot] chore(deps): bump hadolint/hadolint-action from 1.6.0 to 2.1.0
- #5110: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 215 to 216 in /tests/apps/php
- #5104: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 214 to 215 in /tests/apps/php
- #5097: @dependabot[bot] chore(deps): bump werkzeug from 2.1.0 to 2.1.1 in /tests/apps/python-flask
- #5098: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 213 to 214 in /tests/apps/php
- #5096: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.8 to 11.0.9 in /tests/apps/java
- #5091: @josegonzalez Update all dependencies for multi test app
- #5089: @dependabot[bot] chore(deps): bump minimist from 1.2.5 to 1.2.6 in /tests/apps/multi
- #5081: @dependabot[bot] chore(deps): bump jinja2 from 3.0.3 to 3.1.1 in /tests/apps/python-flask
- #5071: @dependabot[bot] chore(deps): bump monolog/monolog from 1.26.1 to 1.27.0 in /tests/apps/php
- #5075: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 212 to 213 in /tests/apps/php
- #5082: @dependabot[bot] chore(deps): bump werkzeug from 2.0.3 to 2.1.0 in /tests/apps/python-flask
- #5086: @dependabot[bot] chore(deps): bump flask from 2.0.3 to 2.1.1 in /tests/apps/multi
- #5087: @dependabot[bot] chore(deps): bump flask from 2.0.3 to 2.1.1 in /tests/apps/python-flask
- #5067: @dependabot[bot] chore(deps): bump maven-dependency-plugin from 3.2.0 to 3.3.0 in /tests/apps/java
# History
## 0.27.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.0/bootstrap.sh
sudo DOKKU_TAG=v0.27.0 bash bootstrap.sh
```
See the [0.27.0 migration guide](/docs/appendices/0.27.0-migration-guide.md) for more information on migrating to 0.27.0.
### Bug Fixes
- #5063: @josegonzalez Fix buildx support for releases
- #5061: @josegonzalez Use correct token when publish unit test results
- #5057: @josegonzalez Ensure we use the correct variable for WAIT
- #5052: @josegonzalez Run crontab under sudo to support rhel systems
- #5051: @josegonzalez Ensure vector component sources have valid names
- #5035: @nerg4l Fix help flag for logs command
- #5019: @josegonzalez Only rename app domains associated with a global domain
### New Features
- #5064: @josegonzalez Upgrade docker image to ubuntu focal
- #5058: @josegonzalez Add .shellcheckrc
- #5055: @josegonzalez Release dokku for 32-bit Raspbian Bullseye
- #5050: @josegonzalez Set the default memory unit type to megabytes
- #5017: @josegonzalez Add command to clear all proxy configs
### Refactors
- #4921: @josegonzalez Add ability to filter returnable apps
### Documentation
- #5056: @miku86 Fix typo in port management docs
- #5018: @josegonzalez Add warning for setting PORT environment variable
### Other
- #5062: @dependabot[bot] chore(deps): bump django from 3.1.13 to 3.1.14 in /tests/apps/dockerfile-release
- #5053: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 211 to 212 in /tests/apps/php
- #5038: @dependabot[bot] chore(deps): bump flask from 2.0.2 to 2.0.3 in /tests/apps/multi
- #5048: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 210 to 211 in /tests/apps/php
- #5039: @dependabot[bot] chore(deps): bump sinatra from 2.1.0 to 2.2.0 in /tests/apps/ruby
- #5037: @dependabot[bot] chore(deps): bump flask from 2.0.2 to 2.0.3 in /tests/apps/python-flask
- #5036: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 207 to 210 in /tests/apps/php
- #5025: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.7 to 11.0.8 in /tests/apps/java
- #5026: @dependabot[bot] chore(deps): bump werkzeug from 2.0.2 to 2.0.3 in /tests/apps/python-flask
- #5027: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 206 to 207 in /tests/apps/php
- #5021: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 205 to 206 in /tests/apps/php
- #4975: @tcurdt add arm64 to the build
dquote>
dquote> This is a minimal config that can be used in conjunction with text editors to run linting during development. The initial rules are a subset of those we ignore across the codebase. A future update will add further rules as needed and cleanup the codebase.
RHEL blocks users from executing crontab as themselves Because Of Reasons so we need to use sudo instead.
Also refactors file writing to properly support writing the permissions on sudoers files going forward.
Closes#5020
Ideally we could use this to mock out different plugin paths with test implementations of user-auth-app, but for now setting something that won't generally fail is good enough.
This increases the time to list apps from .05s to .2s~.3s on the simplest check, but the increased time is worth it for actually verifyng access to an app (should that need arise).
We'll also want to add the same to app existence checks.
# History
## 0.26.8
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.8/bootstrap.sh
sudo DOKKU_TAG=v0.26.8 bash bootstrap.sh
```
### Bug Fixes
- #5016: @josegonzalez Properly support the --global flag when detecting the scheduler
- #5015: @josegonzalez Avoid popd errors when dokku is run as root
### New Features
- #5006: @josegonzalez Better go mod support in VSCode Dev Containers
### Documentation
- #5014: @josegonzalez Clarify that all run containers are removed at the end of process execution
- #5010: @josegonzalez Add documentation for ps:restore
- #5009: @josegonzalez Clarify installation documentation
When running the dokku command in a directory that the dokku user does not have access to - such as /root - popd will fail loudly (starting in Ubuntu 16.04). This change ignores those errors and changes the working dir in the bin to /tmp.
Refs #5012
# History
## 0.26.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.7/bootstrap.sh
sudo DOKKU_TAG=v0.26.7 bash bootstrap.sh
```
### Bug Fixes
- #5003: @josegonzalez Respect pre-existing .env files when preparing the herokuish buildenv
- #4950: @emdienn Use exported environment vars during pack build
- #4999: @elhu Purge cache for all apps when calling buildpacks:set-property with --global flag
- #4988: @fomojola Conditionally restart NGINX
- #4922: @josegonzalez Gitignore more built plugin triggers in apps plugin
### New Features
- #4964: @josegonzalez Add log message when running state is false
- #4970: @josegonzalez Log the string error and not bytes when there is an issue updating the cron schedule
- #4924: @josegonzalez Update devcontainer to include aliased go packages
- #4920: @josegonzalez Ensure related go source and vscode plugins are installed in devcontainer
### Documentation
- #4949: @IlyaSemenov docs: update herokuish upgrade instructions
- #4992: @anthonyshew Typo for deploying using image SHA
- #4976: @josegonzalez Update link in header to dokku pro
- #4972: @Dam-Buty Clarify cron:report command
- #4943: @Stormheg Fix typo in registry management documentation
- #4935: @josegonzalez Reword note about env vars in nginx config templates
### Other
- #4995: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 203 to 205 in /tests/apps/php
- #4978: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 201 to 203 in /tests/apps/php
- #4936: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 200 to 201 in /tests/apps/php
- #4937: @dependabot[bot] chore(deps): bump socket.io from 4.3.2 to 4.4.0 in /tests/apps/.websocket.disabled
The command for using an image doesn't include a colon before the `@sha`. Just wanted to help out others because this was tripping me up for like an hour!
Before restarting nginx, check if the current app is using a proxy and if the selected proxy is in fact NGINX. Only then should we bother invoking the nginx reload.
Fixes https://github.com/dokku/dokku/issues/4987
These don't get installed by the go list hack for various reasons. While it would be best to download the _exact_ versions in use, installing the "latest" is better than nothing for local development.
# History
## 0.26.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.6/bootstrap.sh
sudo DOKKU_TAG=v0.26.6 bash bootstrap.sh
```
### Bug Fixes
- #4919: @nerg4l fix: do not validate global flag as an app name
- #4918: @josegonzalez Use netrc binary to properly release dokku client homebrew formula
# History
## 0.26.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.4/bootstrap.sh
sudo DOKKU_TAG=v0.26.4 bash bootstrap.sh
```
### Bug Fixes
- #4899: @josegonzalez Ensure we respect quotes and dollar signs in config vars
- #4890: @josegonzalez Drop which in favor of command -v
### Other
- #4897: @josegonzalez Silence errors when verifying the ssl certificate
- #4891: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 199 to 200 in /tests/apps/php
Due to various changes in how containers are started, these keys were set incorrectly for apps. Since we can use the short-hand --env=ENV format for setting env vars on docker containers, lets do so.
Closes#4895Closes#4896
# History
## 0.26.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.3/bootstrap.sh
sudo DOKKU_TAG=v0.26.3 bash bootstrap.sh
```
### Bug Fixes
- #4889: @josegonzalez Skip herokuish version in report output and disable the herokuish builder on armhf architectures
We don't skip pack as in theory they may be able to support arm in the future. Dockerfile builds should work fine, as long as all images in the FROM directives have arm versions.
Finally, the null builder _should_ always work, but of course YMMV :D
# History
## 0.26.2
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.2/bootstrap.sh
sudo DOKKU_TAG=v0.26.2 bash bootstrap.sh
```
### Bug Fixes
- #4888: @josegonzalez Ensure installations treat raspbian as similar to debian buster as possible
- #4887: @josegonzalez Ensure we do not add two debian folders in a single armhf package
### New Features
- #4886: @josegonzalez Add created-at time to apps:report output
# History
## 0.26.1
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.1/bootstrap.sh
sudo DOKKU_TAG=v0.26.1 bash bootstrap.sh
```
### Bug Fixes
- #4884: @josegonzalez Correct recommends entry for bash-completion
### New Features
- #4885: @josegonzalez Add experimental support for arm devices
This specifically targets Raspbian Buster, though releases may work on other debian-based operating systems.
Note that this does _not_ port buildpacks - either herokuish or pack - to Raspbian, and it is likely that users will need to use pack for buildpack support (if/when it is supported on ARM) or Dockerfile for image building.
# History
## 0.26.0
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.26.0/bootstrap.sh
sudo DOKKU_TAG=v0.26.0 bash bootstrap.sh
```
See the [0.26.0 migration guide](/docs/appendices/0.26.0-migration-guide.md) for more information on migrating to 0.26.0.
### Bug Fixes
- #4882: @josegonzalez Add missing setup/teardown of builder plugin properties
- #4880: @josegonzalez Ensure the null scheduler reports the app as running when in use
- #4871: @josegonzalez Do not error when default Procfile path does not exist when using a custom procfile-path
- #4861: @josegonzalez Add missing clone/rename code for plugins
### New Features
- #4864: @josegonzalez Switch to unauthenticated tap for formula bumping
- #4860: @josegonzalez Add ability to increase the max parallelism when deploying a given process type
### Documentation
- #4883: @josegonzalez Enable vertical scrolling on the version selector
- #4879: @josegonzalez Clarify that the docker-based dokku installation is ready when a certain message appears
- #4863: @josegonzalez Clarify what is necessary for implementing a scheduler plugin
### Other
- #4874: @josegonzalez Upgrade vector log integration to 0.17.x
- #4881: @josegonzalez Drop bindutils as alternative dependency to bind-utils
- #4869: @dependabot[bot] chore(deps): bump socket.io from 4.2.0 to 4.3.0 in /tests/apps/.websocket.disabled
- #4868: @dependabot[bot] chore(deps): bump jetty-servlet from 11.0.6 to 11.0.7 in /tests/apps/java
- #4866: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 198 to 199 in /tests/apps/php
- #4862: @josegonzalez Set deploy-source and metadata at deploy time
- #4853: @josegonzalez Remove dangling images
- #4765: @josegonzalez Allow specifying a single process type to restart
- #4859: @josegonzalez Remove deprecated tar plugin
- #4858: @josegonzalez Remove deprecated tags plugin
- #4857: @josegonzalez Implement scheduler management plugin
We now have too many versions for it to show up on a modern-ish laptop screen, so enabling scrolling will allow folks to choose older versions more easily.
Previously, stderr was ignored when tailing container log output in golang. This change ensures we capture it and also use the correct helper for that output method.
Unfortunately, this breaks CentOS compatibility as they use an older version of yum in CentOS 7. Rather than inconvenience the larger user base, Photon users may wish to provide their own `bind-utils` metapackage that depends on `bindutils`.
Closes#4852
This ensures the value is correct, where previously it was computed based on a file - and therefore did not distinguish between git:from-archive and git:from-image.
Closes#4464
Dokku currently injects an alternate tag into the image. Without this change, deploying new image tags (via push with a Dockerfile or git:from-image) would result in the old images lying around forever. This change ensures they are registered for removal.
Closes#4825
This ensures that unused docker images are _also_ removed. While this will mean a `ps:start` requires a rebuild in the case of a force-stop, it ensures we don't have unused images when destroying apps.
This changes restarts to drop the 'release' part that currently gets triggered, which also helps reduce the possibility that a new image layer will be added due to predeploy deploy triggers.
Note that the old method essentially halfway-rebuilt the app (which was what added the extra layer). This refactor removes that, which is a bc-break.
Additionally, scaling processes will result in deploying _only_ restarting the processes being scaled.
Closes#2184
# History
## 0.25.7
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.7/bootstrap.sh
sudo DOKKU_TAG=v0.25.7 bash bootstrap.sh
```
### Bug Fixes
- #4855: @josegonzalez Output remote client help when there is no remote host
### New Features
- #4854: @josegonzalez Fix parallel usage for scheduler-docker-local
### Documentation
- #4856: @josegonzalez Add a note to the migration guide regarding using a Procfile for Dockerfile deploys
- #4843: @schmijos Clarify that docker-options are not passed to the launched process but instead to the docker run command
### Other
- #4844: @dependabot[bot] chore(deps): bump werkzeug from 2.0.1 to 2.0.2 in /tests/apps/python-flask
# History
## 0.25.6
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.6/bootstrap.sh
sudo DOKKU_TAG=v0.25.6 bash bootstrap.sh
```
### Bug Fixes
- #4841: @josegonzalez Ensure pack is run as root user when building apps in docker
- #4836: @josegonzalez Fix custom dockerfile path detection
- #4839: @josegonzalez Choose the correct app when a named remote is specified in the remote ssh client
### New Features
- #4829: @josegonzalez Add ability to schedule process types in parallel
- #4837: @josegonzalez Filter --link and --volume flags during Dockerfile builds
### Documentation
- #4840: @josegonzalez Explain sha256 image digest alternative when reusing docker image tags for git:from-image deployments
### Tests
- #4842: @josegonzalez Set default process list in test cnb buildpacks
### Other
- #4832: @dependabot[bot] chore(deps): bump flask from 2.0.1 to 2.0.2 in /tests/apps/python-flask
- #4833: @dependabot[bot] chore(deps): bump jinja2 from 3.0.1 to 3.0.2 in /tests/apps/python-flask
- #4831: @dependabot[bot] chore(deps): bump flask from 2.0.1 to 2.0.2 in /tests/apps/multi
The link flag was previously not filtered _after_ fetching build args for dockerfile builds, which meant if a plugin exposed that in it's own docker-args-build trigger, it would break deploys.
Additionally, allow for whitespaces between link and volume flags.
# History
## 0.25.5
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.5/bootstrap.sh
sudo DOKKU_TAG=v0.25.5 bash bootstrap.sh
```
### Bug Fixes
- #4787: @josegonzalez Do not require double quotes when issuing dokku run commands
- #4816: @josegonzalez Set the DOKKU_HOST_ROOT on docker container start
- #4810: @josegonzalez Handle udp ports when fetching network config
- #4812: @josegonzalez Silence stderr when fetching a command from the Procfile
- #4800: @josegonzalez Add help2man os package for copyfiles make target to devcontainer
- #4796: @josegonzalez Remove the --restart flag from pre-deploy chown containers
### New Features
- #4809: @josegonzalez Implement storage:ensure-directory command
- #4801: @josegonzalez Expose git-from-archive and git-from-image plugin triggers
- #4785: @josegonzalez Add support for VSCode Dev Containers
### Documentation
- #4819: @stephenheron Fixed typo in tar documentation
- #4824: @dy3l Fix GitLab case
- #4822: @josegonzalez Add a note about using the registry:login command for private image deployments
- #4808: @francipvb Added a comment about Dockerfile deployment
- #4807: @FinnWoelm Docs: Fix instructions for enabling Docker Buildkit
- #4786: @josegonzalez Add missing argument from trigger documentation
- #4780: @adam12 Update source for `dokku-update`
### Tests
- #4828: @josegonzalez Update golang in test apps to latest version
- #4815: @josegonzalez tests: use python3 shebang for shellcheck-to-junit script
- #4814: @josegonzalez Add wget to devcontainer to fix shfmt installation
- #4791: @josegonzalez Fix test running in devcontainer
### Other
- #4813: @dependabot[bot] chore(deps-dev): bump heroku/heroku-buildpack-php from 197 to 198 in /tests/apps/php
- #4802: @dependabot[bot] chore(deps): bump django from 3.1.12 to 3.1.13 in /tests/apps/dockerfile-release
- #4784: @josegonzalez Upgrade vector image to 0.16.x
When deploying, if the procfile-get-command fails for a given process, this causes an error to output to stderr. We instead silence this as the error isn't important.
When an app only has UDP ports exposed, deploys will fail as we expect there to be a single TCP port.
While we _should_ support both, the easier fix is to ignore things and move on. Users can manually expose UDP ports as necessary via the -p flag (or by not specifying the port as a UDP port).
One quirk discovered during tests is that disabling zero-downtime deploys results in odd output, but also a deploy can succeed even if one of the processes that skipped zero-downtime fails. We should fix this in another PR, but this is documented in tests for now.
Closes#4804
# History
## 0.25.4
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.4/bootstrap.sh
sudo DOKKU_TAG=v0.25.4 bash bootstrap.sh
```
### Bug Fixes
- #4775: @josegonzalez Add support for url-encoded vector-sink config values …
- #4777: @josegonzalez Set correct version for registry plugin
### Documentation
- #4776: @josegonzalez Clarify valid values for container-type when entering containers
### Other
- #4774: @dependabot[bot] chore(deps): bump sqlparse from 0.4.1 to 0.4.2 in /tests/apps/dockerfile-release
Previously, a user could inadvertently override the type or the inputs value by specifying those in their config. Instead, we force-set these so that users do not have potentially invalid config.
# History
## 0.25.3
Install/update via the bootstrap script:
```shell
wget https://raw.githubusercontent.com/dokku/dokku/v0.25.3/bootstrap.sh
sudo DOKKU_TAG=v0.25.3 bash bootstrap.sh
```
### Bug Fixes
- #4767: @josegonzalez Output logs when container rename fails and continue on
- #4764: @josegonzalez Reference correct plugin when setting up app-json plugin
### Refactors
- #4741: @josegonzalez Use a Dockerfile to speed up env var injection for herokuish app builds
### Documentation
- #4763: @josegonzalez Remove install doc references to removed web installer
### Other
- #4766: @josegonzalez Capitalize certain log messages for aesthetic reasons
This allows folks to later investigate why the rename failed (probably an app bug) and helpfully posts the container logs.
If multiple containers fail, they may have a ton of output, but this is better than not knowing what is going on.
Closes#3900
This makes it easier to track a Dokku container vs an intermediate container or something created external to Dokku.
The container is properly renamed later on, so the `upcoming` part is just an indicator that the container has potentially not yet passed healthchecks.
Herokuish app builds currently spin up a temporary container and then commit that container. The new approach uses a Dockerfile to perform those same actions, avoiding the need for the temporary container.
2021-08-18 03:16:11 -04:00
394 changed files with 9568 additions and 2775 deletions
Consider [sponsoring Dokku](https://github.com/sponsors/dokku). Sponsorship goes directly to supporting activities such as fixing bugs and general maintenance.
- type:textarea
id:description
attributes:
label:Description of problem
description:What happened? What did you expect to happen?
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce
description:What are the steps that we need to follow to reproduce this issue?
validations:
required:true
- type:textarea
id:report-output
attributes:
label:dokku report $APP_NAME
description:Please paste the output of the command `dokku report $APP_NAME`, where `$APP_NAME` is the name of your app
validations:
required:true
- type:textarea
id:additional-output
attributes:
label:Additional information
description:|
This information is useful for debugging app issues:
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable)
If a deploy is failing or behaving unexpectedly:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- If using buildpacks, which custom buildpacks are in use
- If using a Dockerfile, the contents of that file
- If it exists, the contents of your Procfile.
validations:
required:false
- type:textarea
id:logs
attributes:
label:"Output of failing commands after running: dokku trace:off"
render:shell
validations:
required:false
- type:textarea
id:trace-logs
attributes:
label:"Output of failing commands after running: dokku trace:on"
description:|
**BEWARE**: `dokku trace:on` will cause some commands to print environment variables, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXX
description:Is your deploy failing while building your application using buildpacks? Check this out.
labels:["upstream: buildpacks"]
body:
- type:markdown
attributes:
value:|
If your build is stuck downloading something, compiling a file, or seems to always fail around the same area, Github Issues is not a great place to debug. This is because these sorts of issues tend to take a lot of back and forth to figure out, and the code for buildpacks is not generally maintained by the Dokku project.
<details>
<summary>Debugging tips:</summary>
- If you see text that says `Killed` in your output, attempt to increase free memory by using a larger server or [add swap memory](https://dokku.com/docs/getting-started/troubleshooting/#build-fails-with-killed-message).
- Turn on buildpack trace mode via `dokku config:set $APP_NAME BUILDPACK_XTRACE=1` and retry your deploy. Not all buildpacks support this, but many will output extra debugging information.
- Your hosting provider may have issues accessing AWS S3. Verify a slow/stalled download works by directly curling the file from your host.
- Many buildpacks allow downloading a file from an alternative location specified via environment variable.
- [Increase curl timeouts](https://dokku.com/docs/getting-started/troubleshooting/#deployment-fails-because-of-slow-internet-connection-messages-s) if you see gzip download issues.
- If using multi-buildpack support but a buildpack is failing to apply, ensure you have any files necessary for the `bin/detect` script of the buildpack to `exit 0`. Selected buildpacks must still pass the detection phase in order to be used.
</details>
If you are still having issues, file a ticket here and then further discussing the ticket in one of our [Monitored Support Channels](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations) (Discord, Github Discussions, Slack). Your filed ticket may be closed or locked, but any subsequent discovery will be posted to the ticket for posterity.
- type:textarea
id:description
attributes:
label:Description of problem
description:What happened? What did you expect to happen?
validations:
required:true
- type:textarea
id:report-output
attributes:
label:dokku report $APP_NAME
description:Please paste the output of the command `dokku report $APP_NAME`, where `$APP_NAME` is the name of your app.
validations:
required:true
- type:textarea
id:additional-output
attributes:
label:Additional information
description:|
This information is useful for debugging app issues:
- Container Inspect Output (if applicable) via `dokku ps:inspect APP_NAME`
- The nginx configuration (if applicable) via `dokku nginx:show-config APP_NAME`
- Link to the exact repository being deployed (if possible/applicable)
If a deploy is failing or behaving unexpectedly:
- Application name
- The type of application being deployed (node, php, python, ruby, etc.)
- If using buildpacks, which custom buildpacks are in use
- If it exists, the contents of your Procfile.
validations:
required:true
- type:textarea
id:logs
attributes:
label:"Output of failing deploy after running: dokku trace:off"
render:shell
validations:
required:true
- type:textarea
id:trace-logs
attributes:
label:"Output of failing deploy after running: dokku trace:on"
description:|
**BEWARE**: `dokku trace:on` will cause some commands to print environment variables, be sure you're not exposing any sensitive information when posting issues. You may replace these values with XXXXXX
description:Have an idea for a new feature? Ask away!
labels:["needs: plan","type: enhancement"]
body:
- type:markdown
attributes:
value:|
While pull requests are always welcome, feel free to fill this out with an idea of what you would like to happen and we can discuss if and how it should be implemented in Dokku.
Consider [sponsoring Dokku](https://github.com/sponsors/dokku). Sponsorship goes directly to supporting activities such as implementing new features and upgrading existing functionality.
- type:textarea
id:description
attributes:
label:Description of feature
description:When you perform what command or action, what do you think should happen?
> If you'd like to sponsor specific functionality, see the project's [Sponsoring](https://github.com/dokku/.github/blob/master/SPONSORING.md) document.
>
> If you need help figuring out how to use a specific buildpack, are seeing an issue in during the buildpack process, or are having issues using multiple buildpacks, please see our [slack channels or github discussion board](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations). Issues pertaining to buildpacks may be closed and locked.
> If you need help figuring out how to use a specific buildpack, are seeing an issue in during the buildpack process, or are having issues using multiple buildpacks, please see our [chat channels or github discussion board](https://dokku.com/docs/getting-started/where-to-get-help/#monitored-locations). Issues pertaining to buildpacks may be closed and locked.
>
> If you need support for a version of Dokku that is more than a year old, your issue may be closed without an answer. Please upgrade to a recent version.
You can then proceed to the ip address or domain name associated with your server to complete the web-based installation.
You can then proceed to configure your server domain (via `dokku domains:set-global`) and user access (via `dokku ssh-keys:add`) to complete the installation.
If you wish for a more unattended installation method, see [these](https://dokku.com/docs/getting-started/install/debian/#unattended-installation) docs.
@@ -112,7 +101,7 @@ If you wish for a more unattended installation method, see [these](https://dokku
## Documentation
Full documentation - including advanced installation docs - are available online at [https://dokku.com/docs/getting-started/installation/](https://dokku.com/docs/getting-started/installation/).
Full documentation - including advanced installation docs - are available online at <https://dokku.com/docs/getting-started/installation/>.
Pass [options](https://docs.docker.com/engine/reference/run/) to Docker during Dokku's `build`, `deploy` and `run` phases
Pass [container options](https://docs.docker.com/engine/reference/run/) to the `docker run` command during Dokku's `build`, `deploy` and `run` phases
```
docker-options:add <app> <phase(s)> OPTION # Add Docker option to app for phase (comma-separated phase list)
@@ -29,6 +29,8 @@ Manipulation of docker options will not restart running containers. This enables
More information on supported Docker options can be found here: https://docs.docker.com/engine/reference/commandline/run/.
Container options configured via the `docker-options` plugin are not used to modify the process a container runs. Container options are the `[OPTIONS]` portion of the following, where `[CONTAINER_COMMAND]` and `[ARG]` are the process and the arguments passed to it that are launched in the created container: `docker run [OPTIONS] [CONTAINER_COMMAND] [ARG...]`. Please see the documentation for [customizing the run command](/docs/deployment/builders/dockerfiles.md#customizing-the-run-command) or use a [Procfile](/docs/deployment/builders/dockerfiles.md#procfiles-and-multiple-processes) to modify the command used by a Dockerfile-based container.
The preferred method to mount external containers to a Dokku managed container, is to use the Dokku storage plugin.
```
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
storage:ensure-directory [--chown option] <directory> # Creates a persistent storage directory in the recommended storage path
storage:list <app> # List bind mounts for app's container(s) (host:container)
storage:mount <app> <host-dir:container-dir> # Create a new bind mount
storage:report [<app>] [<flag>] # Displays a checks report for one or more apps
storage:unmount <app> <host-dir:container-dir> # Remove an existing bind mount
```
> The storage plugin is compatible with storage mounts created with the docker-options. The storage plugin will only list mounts from the deploy/run phase.
@@ -20,50 +21,77 @@ The storage plugin supports the following mount points:
## Usage
This example demonstrates how to mount the recommended directory to `/storage` inside an application called `node-js-app`. For simplicity, the Dokku project recommends using the directory `/var/lib/dokku/data/storage` directory as the root host path for mounts. This directory is created on Dokku installation.
### Creating storage directories
> New as of 0.25.5
A storage directory can be created with the `storage:ensure-directory` command. This command will create a subdirectory in the recommended `/var/lib/dokku/data/storage` path - created during Dokku installation - and prepare it for use with an app.
```shell
# we use a subdirectory inside of the host directory to scope it to just the app
Dokku will then mount the shared contents of `/var/lib/dokku/data/storage/node-js-app` to `/storage` inside the container. Mounts are only available for containers crated via `run` and by the deploy process, and not during the build process. In addition, the host path is never auto-created by either Dokku or Docker, and should be an explicit path, not one relative to the current working directory.
> If the `/storage` path within the container had pre-existing content, the container files will be overrwritten. This may be an issue for users that create assets at build time but then mount a directory at the same place during runtime. Files are not merged.
By default, permissions are set for usage with Herokuish buildpacks. These permissions can be changed via the `--chown` option according to the following table:
Once you have mounted persistent storage, you will also need to restart the application. See the
[process scaling documentation](/docs/processes/process-management.md) for more information.
-`--chown herokuish` (default): Use `32767:32767` as the folder permissions.
- This is used for apps deployed with Buildpacks via Herokuish.
-`--chown heroku`: Use `1000:1000` as the folder permissions.
- This is used for apps deployed with Cloud Native Buildpacks using the `heroku/buildpacks` builder.
-`--chown packeto`: Use `2000:2000` as the folder permissions.
- This is used for apps deployed with Cloud Native Buildpacks using the `cloudfoundry/cnb` or `packeto` builders.
-`--chown false`: Skips the `chown` call.
Users deploying via Dockerfile will want to specify `--chown false` and manually `chown` the created directory if the user and/or group id of the runnning process in the deployed container do not correspond to any of the above options.
> Warning: Failing to set the correct directory ownership may result in issues in persisting files written to the mounted storage directory.
### Mounting storage into apps
Dokku supports mounting both explicit host paths as well as docker volumes via the `storage:mount` command. This takes two arguments, an app name and a `host-path:container-path` or `docker-volume:container-path` combination.
```shell
# mount the directory into your container's /app/storage directory, relative to the container root (/)
# explicit host paths _must_ exist prior to usage.
In the first example, Dokku will then mount the shared contents of `/var/lib/dokku/data/storage/node-js-app` to `/app/storage` inside the container. The mount point is *not* relative to your app's working directory, and is instead relative to the root (`/`) of the container. Mounts are only available for containers created via `run` and by the deploy process, and not during the build process. In addition, the host path is never auto-created by either Dokku or Docker, and should be an explicit path, not one relative to the current working directory.
> If the `/storage` path within the container had pre-existing content, the container files will be over-written. This may be an issue for users that create assets at build time but then mount a directory at the same place during runtime. Files are not merged.
Once persistent storage is mounted, the app requires a restart. See the [process scaling documentation](/docs/processes/process-management.md) for more information.
```shell
dokku ps:restart app-name
```
A more complete workflow may require making a custom directory for your application and mounting it within your `/app/storage` directory instead. The mount point is *not* relative to your application's working directory, and is instead relative to the root (`/`) of the container.
### Unmounting storage
If an app no longer requires a mounted volume or directory, the `storage:unmount` command can be called. This takes the same arguments as the `storage:mount` command, an app name and a `host-path:container-path` or `docker-volume:container-path` combination.
```shell
# creating storage for the app 'node-js-app'
mkdir -p /var/lib/dokku/data/storage/node-js-app
# unmount the directory from your container's /app/storage directory, relative to the container root (/)
You can mount one or more directories as desired by following the above pattern.
Once persistent storage is unmounted, the app requires a restart. See the [process scaling documentation](/docs/processes/process-management.md) for more information.
### Directory Permissions
The host directory should always be owned by the container user and group id. If this is not the case, files may not persist when written to mounted storage.
- Buildpacks via Herokuish: Use `32767:32767` as the file permissions
- For Cloud Native Buildpacks: This will depend on the builder in question, but can be retrieved via the `CNB_USER_ID` and `CNB_GROUP_ID` environment variables on the builder image. Common builders are as follows:
- heroku/buildpacks: `1000:1000`
- cloudfoundry/cnb: `2000:2000`
- packeto: `2000:2000`
- Dockerfile and Docker Image: Use the user and group id which corresponds to the one running the process within the container.
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web applications, like user uploads or large binary assets like images, a directory outside the container should be mounted.
Dokku is powered by Docker containers, which recommends in their [best practices](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#containers-should-be-ephemeral) that containers be treated as ephemeral. In order to manage persistent storage for web apps, like user uploads or large binary assets like images, a directory outside the container should be mounted.
### Shared storage between containers
@@ -139,11 +167,11 @@ You cannot use mounted volumes during the build phase of a Dockerfile deploy. Th
> Note: **This can cause data loss** if you bind a mount under `/app` in buildpack apps as herokuish will attempt to remove the original app path during the build phase.
## Application User and Persistent Storage file ownership (buildpack apps only)
## App User and Persistent Storage file ownership (buildpack apps only)
> New as of 0.7.1
By default, Dokku will execute your buildpack application processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
By default, Dokku will execute your buildpack app processes as the `herokuishuser` user. You may override this by setting the `DOKKU_APP_USER` config variable.
> NOTE: this user must exist in your herokuish image.
To push the image on release, set the `push-on-release` property to `true` via the `registry:set` command. The default value for this property is `false`. Setting the property to `true` will result in the imag being tagged with an ID that is incremented with every release. This tag will be what is used for running app code.
To push the image on release, set the `push-on-release` property to `true` via the `registry:set` command. The default value for this property is `false`. Setting the property to `true` will result in the image being tagged with an ID that is incremented with every release. This tag will be what is used for running app code.
@@ -9,6 +9,8 @@ The [dokku-registry](https://github.com/dokku/dokku-registry) plugin is now buil
- At this time, remote docker repositories are not automatically created for AWS, and users must create those repositories for their applications as necessary. This may be implemented in the future.
- Docker images are only pushed when configured to do so. See the [registry management documentation](/docs/deployment/registry-management.md) for more details.
Before upgrading, uninstall the registry plugin via `dokku plugin:uninstall registry`. Not doing so will cause issues with Dokku.
## Other
### Changes
@@ -18,13 +20,14 @@ The [dokku-registry](https://github.com/dokku/dokku-registry) plugin is now buil
- The `pre-deploy` plugin trigger is now called internally by Dokku. Scheduler plugins should avoid calling this trigger, as any image changes introduced by subsequent trigger calls will be ignored.
- The default image used for Herokuish Buildpack builds is now `gliderlabs/herokuish:latest-20`, and is based on both the `heroku-20` stack as well as Ubuntu 20.04. Users that wish to stick with the old, `heroku-18`/Ubuntu 18.04 builder may specify `gliderlabs/herokuish:latest-18` as their builder image. Please see the [herokuish buildpack deployment documentation](/docs/deployment/builders/herokuish-buildpacks.md#customizing-the-buildpack-stack-builder) for more information on how to specify a custom buildpack stack builder.
- This change does not impact any users of Cloud Native Buildpacks.
- We fixed an issue that required extracting Procfiles at the beginning of a deploy. Due to this change, a `Dockerfile` app contains a `Procfile` that does not specify a `web` process will fail to start. Usage of a `Procfile` with _only_ a `release` command should be replaced with a `scripts.dokku.postdeploy` deployment task in the `app.json` file. The alternative is to define the `web` process in the `Procfile`. See the [deployment task documentation](/docs/advanced-usage/deployment-tasks.md) for more information.
### Deprecations
- In previous versions of Dokku, the only way to specify a custom `Dockerfile` was to use the `docker-options` plugin to set the `--file` flag for a docker build. As of 0.25.0, the `builder-dockerfile:set` command should be used instead, as outlined in the [docs here](/docs/deployment/builders/dockerfiles.md#changingthe-dockerfile-location). Usage of the old method should be migrated to the new method.
- The `--rm` and `--rm-container` flags may be specified but no longer have any effect on `dokku run`.
- The `--detach` flag is deprecated in favor of the `run:detached` command.
- The `DOKKU_SCALE` file is deprecated. Please see the [process management documentation](/docs/processes/process-management.md#manually-managing-process-scaling) for more information on it's replacement with the `formations` key of the `app.json` file.
- The `DOKKU_SCALE` file is deprecated. Please see the [process management documentation](/docs/processes/process-management.md#manually-managing-process-scaling) for more information on it's replacement with the `formation` key of the `app.json` file.
- The hooks `post-release-buildpack`, `post-release-dockerfile`, and `post-release-pack` are deprecated in favor of `post-release-builder`. See the [plugin triggers documentation](https://dokku.com/docs/development/plugin-triggers/#post-release-builder) for more details.
- The `tags` plugin - deprecated in [0.24.0](/docs/appendices/0.24.0-migration-guide.md) - was removed. Users are highly encouraged to switch their workflows to `git:from-image`.
- The `tar` plugin - deprecated in [0.24.0](/docs/appendices/0.24.0-migration-guide.md) - was removed. Users are highly encouraged to switch their workflows to `git:from-archive`.
## Changes
- The `scheduler` plugin now controls the scheduler in use for deploys. Apps will have their `DOKKU_SCHEDULER` environment variables migrated to the scheduler plugin, after which that value will be removed from said app. Please see the [scheduler documentation](/docs/deployment/schedulers/scheduler-management.md) for more information.
- The `deploy-source` metadata from `apps:report` is now no longer computed on the fly, but hydrated at deploy time via the `deploy-source-set` trigger. This value may be empty until your next deploy.
- Additionally, the `deploy-source` trigger has now been removed.
See [documentation here](https://www.npmjs.com/package/dokku-toolbelt) for more information.
## (python) dokku-client
dokku-client is an extensible python-based cli wrapper for remote Dokku hosts. You can install it via the following shell command (assuming you have python and pip installed):
```shell
pip install dokku-client
```
See [documentation here](https://github.com/adamcharnock/dokku-client) for more information.
## (ruby) Dokku CLI
Dokku CLI is a rubygem that acts as a client for your Dokku installation. You can install it via the following shell command (assuming you have ruby and rubygems installed):
@@ -116,13 +117,15 @@ The following plugins are available and provided by Dokku maintainers. Please f
<sup>1</sup> Extends app.json support to include creating volumes and creating / linking databases on push
<sup>2</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>2</sup> Adds SQLite replication to external object storage via [Litestream](https://litestream.io)
<sup>3</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>3</sup> Adds the possibility to add SSH deployment keys to receive private hosted packages
<sup>4</sup> Adds the ability to sync an application repo with a remote GitHub repo (useful for automated rebuilds without needing a git push from an external system
<sup>4</sup> Adds the ability to add custom hosts to the containers known_hosts file to be able to ssh them easily (useful with deployment keys)
<sup>5</sup> Adds the ability to invoke a post-deploy webhook with the IP, port and app name, all with a single config:set).
<sup>5</sup> Adds the ability to sync an application repo with a remote GitHub repo (useful for automated rebuilds without needing a git push from an external system
<sup>6</sup> Adds the ability to invoke a post-deploy webhook with the IP, port and app name, all with a single config:set).
### Other Plugins
@@ -238,6 +241,7 @@ The following plugins are no longer maintained by their developers.
config:set [--encoded] [--no-restart] (<app>|--global) KEY1=VALUE1 [KEY2=VALUE2 ...] Set one or more config vars
config:unset [--no-restart] (<app>|--global) KEY1 [KEY2 ...] Unset one or more config vars
```
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available _only_ during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860).
> For security reasons - and as per [docker recommendations](https://github.com/docker/docker/issues/13490) - Dockerfile-based deploys have variables available _only_ during runtime, as noted in [this issue](https://github.com/dokku/dokku/issues/1860). Consider using [build arguments](/docs/deployment/builders/dockerfiles.md#build-time-configuration-variables) to expose variables during build-time for Dockerfile apps.
Environment variables are available both at run time and during the application build/compilation step for buildpack-based deploys.
@@ -289,7 +289,7 @@ Unsetting this value is the same as enabling custom nginx config usage.
Finally, each process type has it's network listeners - a list of IP:PORT pairs for the respective app containers - exposed via an `.DOKKU_APP_${PROCESS_TYPE}_LISTENERS` variable - the `PROCESS_TYPE` will be upper-cased with hyphens transformed into underscores. Users can use the new variables to expose non-web processes via the nginx proxy.
> Note: Application config variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
> Note: Application environment variables are available for use in custom templates. To do so, use the form of `{{ var "FOO" }}` to access a variable named `FOO`.
#### Customizing via configuration files included by the default templates
@@ -17,6 +17,7 @@ Dokku supports the following built-in builders:
-`builder-dockerfile`: Builds apps using a `Dockerfile` via `docker build`. See the [dockerfile builder documentation](/docs/deployment/builders/dockerfiles.md) for more information on how this builder functions.
-`builder-herokuish`: Builds apps with Heroku's v2a Buildpack specification via `gliderlabs/herokuish`. See the [herokuish builder documentation](/docs/deployment/builders/herokuish-buildpacks.md) for more information on how this builder functions.
-`builder-null`: Does nothing during the build phase. See the [null builder documentation](/docs/deployment/builders/null.md) for more information on how this builder functions.
-`builder-pack`: Builds apps with Cloud Native Buildpacks via the `pack-cli` tool. See the [cloud native buildpacks builder documentation](/docs/deployment/builders/cloud-native-buildpacks.md) for more information on how this builder functions.
Builders run a detection script against a source code repository, and the first detected builder will be used to build the app artifact. The exception to this is when a `Dockerfile` is detected and the app is also able to use either `herokuish` or `pack-cli` for building, in which case one of the latter will be chosen.
You can get a report about the app's storage status using the `builder-dockerfile:report` command:
```shell
dokku app-json:report
dokku builder-dockerfile:report
```
```
@@ -148,12 +148,8 @@ RUN echo $NODE_ENV
If your Dockerfile is using Docker engine's [buildkit](https://docs.docker.com/develop/develop-images/build_enhancements/) (not to be confused with buildpacks), then the `DOCKER_BUILDKIT=1` environment variable needs to be set. Additionally, complete build log output can be forced via `BUILDKIT_PROGRESS=plain`. Both of these environment variables can be set as follows:
logs:failed [--all|<app>] # Shows the last failed deploy logs
logs:report [<app>] [<flag>] # Displays a logs report for one or more apps
logs:set [--global|<app>] <key> <value> # Set or clear a logs property for an app
@@ -20,6 +20,8 @@ You can easily get logs of an app using the `logs` command:
dokku logs node-js-app
```
Logs are pulled via integration with the scheduler for the specified application via "live tailing". As such, logs from previously running deployments are usually not available. Users that desire to see logs from previous deployments for debugging purposes should persist those logs to external services. Please see Dokku's [vector integration](deployment/logs.md#vector-logging-shipping) for more information on how to persist logs across deployments to ship logs to another service or a third-party platform.
#### Behavioral modifiers
Dokku also supports certain command-line arguments that augment the `log` command's behavior.
@@ -37,7 +39,7 @@ You can use these modifiers as follows:
dokku logs node-js-app -t -p web
```
will show logs continually from the web process.
The above command will show logs continually from the web process.
### Failed deploy logs
@@ -127,6 +129,29 @@ dokku logs:vector-stop
The `vector` container will be stopped and removed from the system. If the container is not running, this command will do nothing.
#### Checking Vector's Logs
It may be necessary to check the vector container's logs to ensure that vector is operating as expected. This can be performed with the `logs:vector-logs` command.
```shell
dokku logs:vector-logs
```
This command also supports the following modifiers:
```shell
--num NUM # the number of lines to display
--tail # continually stream logs
```
You can use these modifiers as follows:
```shell
dokku logs:vector-logs --tail --num 10
```
The above command will show logs continually from the vector container, with an initial history of 10 log lines
#### Configuring a log sink
Vector uses the concept of log "sinks" to send logs to a given endpoint. Log sinks may be configured globally or on a per-app basis by specifying a `vector-sink` in DSN form with the `logs:set` command. Specifying a sink value will reload any running vector container.
@@ -174,4 +199,13 @@ Valid values for `SINK_TYPE` include all log vector log sinks, while `SINK_OPTIO
-`[int]`: form: `key[]=int`
-`table`: form: `option[key]=value`
For some sinks - such as the `http` sink - it may be useful to use special characters such as `&`. These characters must be url escaped as per [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986.html).
```shell
# the following command will set the `http` sink with a uri config value
# for a uri config value: https://loggerservice.com:1234/?token=abc1234&type=vector
# the url quoted version: https%3A//loggerservice.com%3A1234/%3Ftoken%3Dabc1234%26type%3Dvector
dokku logs:set test vector-sink "http://?uri=https%3A//loggerservice.com%3A1234/%3Ftoken%3Dabc1234%26type%3Dvector"
```
Please read the [sink documentation](https://vector.dev/docs/reference/sinks/) for your sink of choice to configure the sink as desired.
@@ -135,7 +135,18 @@ In the above example, Dokku will build the app as if the repository contained _o
FROMdokku/node-js-getting-started:latest
```
Triggering a build with the same arguments multiple times will result in Dokku exiting `0` early as there will be no changes detected.
Triggering a build with the same arguments multiple times will result in Dokku exiting `0` early as there will be no changes detected. If the image tag is reused but the underlying image is different, it is recommended to use the image digest instead of the tag. This can be retrieved via the following command:
The `git:from-image` command can optionally take a git `user.name` and `user.email` argument (in that order) to customize the author. If the arguments are left empty, they will fallback to `Dokku` and `automated@dokku.sh`, respectively.
@@ -143,6 +154,8 @@ The `git:from-image` command can optionally take a git `user.name` and `user.ema
If the image is a private image that requires a docker login to access, the `registry:login` command should be used to log into the registry. See the [registry documentation](/docs/advanced-usage/registry-management.md#logging-into-a-registry) for more details on this process.
Finally, certain images may require a custom build context in order for `ONBUILD ADD` and `ONBUILD COPY` statements to succeed. A custom build context can be specified via the `--build-dir` flag. All files in the specified `build-dir` will be copied into the repository for use within the `docker build` process. The build context _must_ be specified on each deploy, and is not otherwise persisted between builds.
> Warning: As of 0.24.0, this functionality is deprecated in favor of the [`git:from-image`](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) command. It will be removed in a future release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-image`.
>
> New as of 0.4.0
```
tags <app> # List all app image tags
tags:create <app> <tag> # Add tag to latest running app image
tags:deploy <app> <tag> # Deploy tagged app image
tags:destroy <app> <tag> # Remove app image tag
```
The Dokku tags plugin allows you to add Docker image tags to the currently deployed app image for versioning and subsequent deployment.
> When triggering `dokku ps:rebuild APP` on an application deployed via the `tags` plugin, the following may occur:
>
> - Applications previously deployed via another method (`git`/`tar`): The application may revert to a state before the latest custom image tag was deployed.
> - Applications that were only ever deployed via the `tags` plugin: No action will be taken against your application.
>
> Please use the `tags:deploy` command when redeploying an application deployed via Docker image.
## Usage
### Exposed ports
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
### Listing tags for an application
For example, you can list all tags for a given application:
```shell
dokku tags node-js-app
```
```
=====> Image tags for dokku/node-js-app
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
dokku/node-js-app latest 936a42f25901 About a minute ago 1.025 GB
```
### Creating a tag
You can also create new tags for that app using the `tags:create` function. Tags should conform to the Docker tagging specification for your Docker version. As of 1.10, that specification is available [here](https://github.com/docker/docker/blob/master/image/spec/v1.1.md), while users of older versions can check the documentation [here](https://github.com/docker/docker/blob/master/image/spec/v1.md).
```shell
dokku tags:create node-js-app v1
```
```
=====> Added v1 tag to dokku/node-js-app
```
Once the tag is created, you can see the output by running the `tags` command again.
```shell
dokku tags node-js-app
```
```
=====> Image tags for dokku/node-js-app
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
dokku/node-js-app latest 936a42f25901 About a minute ago 1.025 GB
dokku/node-js-app v1 936a42f25901 About a minute ago 1.025 GB
```
### Deploying an image tag
Finally, you can also deploy a local image using the `tags:deploy` command. When specifying a tag that is not `latest`, the released image will be retagged as the `latest` image tag for the app.
> Warning: For images based on Herokuish, using the `tags:deploy` command will reset environment variables written into the image, causing a retag to occur. This will - on average - add two extra layers to your deployed image. Note that this does not affect Dockerfile-based images, which are the majority of images deployed via the `tags` command.
You can alternatively add image pulled from a Docker registry and deploy from it by using tagging feature. In this example, we are deploying from Docker Hub.
1. Create Dokku app as usual.
```shell
dokku apps:create test-app
```
2. Pull image from Docker Hub.
```shell
docker pull demo-repo/some-image:v12
```
3. Retag the image to match the created app.
```shell
docker tag demo-repo/some-image:v12 dokku/test-app:v12
```
4. Deploy tag.
```shell
dokku tags:deploy test-app v12
```
### Deploying an image from CI
To ensure your builds are always reproducible, it's considered bad practice to store build
artifacts in your repository. For some projects however, building artifacts during deployment
to Dokku may affect the performance of running applications.
One solution is to build a finished Docker image on a CI service (or even locally) and deploy
it directly to the host running Dokku.
1. Build image on CI (or locally).
```shell
docker build -t dokku/test-app:v12 .
# Note: The image must be tagged `dokku/<app-name>:<version>`
> Warning: As of 0.24.0, this functionality is deprecated in favor of the [`git:from-archive`](/docs/deployment/methods/git.md#initializing-an-app-repository-from-an-archive-file) command. It will be removed in a future release, and is considered unmaintained. Users are highly encouraged to switch their workflows to `git:from-arhive`.
>
> New as of 0.4.0
```
tar:from <app> <url> # Loads an app tarball from url
tar:in <app> # Reads an tarball containing the app from stdin
```
> When triggering `dokku ps:rebuild APP` on an application deployed via the `tar` plugin, the following may occur:
>
> - Applications previously deployed via another method (`git`): The application may revert to a state before the latest custom image tag was deployed.
> - Applications that were only ever deployed via the `tar` plugin: The application will be properly rebuilt.
>
> Please use the appropriate `tar` command when redeploying an application deployed via tarball.
## Usage
### Deploying from a tarball
In some cases, it may be useful to deploy an application from a tarball. For instance, if you implemented a non-Git based deployment plugin, tarring the generated artifact may be an easier route to interface with the existing Dokku infrastructure.
You can place the tarball on an external webserver and deploy via the `tar:from` command.
Dokku commands can be run over SSH. Anywhere you would run `dokku <command>`, just run `ssh -t dokku@dokku.me <command>`
The `-t` is used to request a pty. It is highly recommended to do so.
To avoid the need to type the `-t` option each time, simply create/modify a section in the `.ssh/config` on the client side, as follows:
To avoid the need to type the `-t` option each time, create/modify a section in the `.ssh/config` on the client side, as follows:
```ini
Host dokku.me
@@ -12,7 +12,7 @@ Host dokku.me
## Behavioral modifiers
Dokku also supports certain command line arguments that augment its behavior. If using these over SSH, you must use the form `ssh -t dokku@dokku.me -- <command>`
in order to avoid SSH interpretting Dokku arguments for itself.
to avoid SSH interpreting Dokku arguments for itself.
```
--quiet suppress output headers
@@ -71,7 +71,7 @@ All commands have the application name automatically set via the `--app` flag on
The client supports several environment variables:
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overriden via `--remote` flag.
-`DOKKU_HOST` (default: `dokku` git remote): Used to interact with a specific remote server. Can be overridden via the `--remote` flag.
-`DOKKU_PORT` (default: `22`): Used to specify a port to connect to the Dokku server on.
It also supports several flags (all flags unspecified here are passed as is to the server):
These scheduler implementations may not be complete, though provide enough functionality for a user to get an app deployed via the underlying scheduler.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
By default, Dokku deploys an app's processes one-by-one in order, with the `web` process being deployed first. Deployment parallelism may be achieved by setting the `parallel-schedule-count` property, which defaults to `1`. Increasing this number increases the number of process types that may be deployed in parallel (with the web process being the exception).
```shell
# Increase parallelism from 1 process type at a time to 4 process types at a time.
If the value of `parallel-schedule-count` is increased and a given process type fails to schedule successfully, then any in-flight process types will continue to be processed, while all process types that have not been scheduled will be skipped before the deployment finally fails.
Container scheduling output is shown in the order it is received, and thus may be out of order in case of output to stderr.
Note that increasing the value of `parallel-schedule-count` may significantly impact CPU utilization on your host as your app containers - and their respective processes - start up. Setting a value higher than the number of available CPUs is discouraged. It is recommended that users carefully set this value so as not to overburden their server.
#### Increasing parallelism within a process deploy
> New as of 0.26.0
By default, Dokku will deploy one instance of a given process type at a time. This can be increased by customizing the `app.json``formation` key to include a `max_parallel` key for the given process type.
An `app.json` file can be committed to the root of the pushed app repository, and must be within the built image artifact in the image's working directory as shown below.
- Buildpacks: `/app/app.json`
- Dockerfile: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
- Docker Image: `WORKDIR/app.json` or `/app.json` (if no working directory specified)
The `formation` key should be specified as follows in the `app.json` file:
```Procfile
{
"formation": {
"web": {
"max_parallel": 1
},
"worker": {
"max_parallel": 4
}
}
}
```
Omitting or removing the entry will result in parallelism for that process type to return to 1 entry at a time. This can be combined with the `parallel-schedule-count` property to speed up deployments.
Note that increasing the value of `max_parallel` may significantly impact CPU utilization on your host as your app containers - and their respective processes - start up. Setting a value higher than the number of available CPUs is discouraged. It is recommended that users carefully set this value so as not to overburden their server.
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `docker-local` scheduler.
### Implemented Commands and Triggers
This plugin implements various functionality through `plugn` triggers to integrate with Docker for running apps on a single server. The following functionality is supported by the `scheduler-docker-local` plugin.
-`check-deploy`
-`core-post-deploy`
-`post-app-clone-setup`
-`post-app-rename-setup`
-`post-create`
-`post-delete`
-`pre-deploy`
-`pre-restore`
-`scheduler-app-status`
-`scheduler-deploy`
-`scheduler-docker-cleanup`
-`scheduler-inspect`
-`scheduler-is-deployed`
-`scheduler-logs`
-`scheduler-logs-failed`
-`scheduler-retire`
-`scheduler-run`
-`scheduler-stop`
-`scheduler-tags-create`
-`scheduler-tags-destroy`
-`apps:clone`
-`apps:destroy`
-`apps:rename`
-`deploy`
-`enter`
-`logs`
-`ps:inspect`
-`ps:stop`
-`run`
## Supported Resource Management Properties
### Logging support
App logs for the `logs` command are fetched from running containers via the `docker` cli. To persist logs across deployments, consider using Dokku's [vector integration](deployment/logs.md#vector-logging-shipping) to ship logs to another service or a third-party platform.
### Supported Resource Management Properties
The `docker-local` scheduler supports a minimal list of resource _limits_ and _reservations_. The following properties are supported:
### Resource Limits
#### Resource Limits
- cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
- See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes).
- memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
- nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
- See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
### Resource Reservations
#### Resource Reservations
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
- memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
- See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
> Warning: This scheduler is not in Dokku core and thus functionality may change over time as the API stabilizes.
The [Nomad Scheduler Plugin](https://github.com/dokku/dokku-scheduler-kubernetes) is available free as an external plugin. Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-kubernetes/issues) for more information on the status of the plugin.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `docker-local` scheduler.
### Implemented Commands and Triggers
This plugin implements various functionality through `plugn` triggers to integrate with `kubectl` for running apps on a Kubernetes cluster. The following functionality is supported by the `scheduler-kubernetes` plugin.
-`apps:destroy`
-`deploy`: partial, does not implement failed deploy log capture
-`logs`: partial, does not implement failure logs
-`ps:stop`
### Logging support
App logs for the `logs` command are fetched from running pods via the `kubectl` cli. To persist logs across deployments, consider using [Vector](https://vector.dev/docs/setup/installation/platforms/kubernetes/) or a similar tool to ship logs to another service or a third-party platform.
> Warning: This scheduler is not in Dokku core and thus functionality may change over time as the API stabilizes.
The [Nomad Scheduler Plugin](https://github.com/dokku/dokku-scheduler-nomad) is available free as an external plugin. Please see the plugin's [issue tracker](https://github.com/dokku/dokku-scheduler-nomad/issues) for more information on the status of the plugin.
For users that require additional functionality, please refer to the [Sponsoring Documentation](https://github.com/dokku/.github/blob/master/SPONSORING.md).
## Scheduler Interface
The following sections describe implemented scheduler functionality for the `docker-local` scheduler.
### Implemented Commands and Triggers
This plugin implements various functionality through `plugn` triggers to integrate with the `nomad` cli for running apps on a Nomad cluster. The following functionality is supported by the `scheduler-nomad` plugin.
-`apps:destroy`
-`deploy`
-`ps:stop`
### Logging support
> Warning: Fetching app logs for the `logs` command is currently not implemented. Please consider using [Vector](https://vector.dev/docs/setup/installation/platforms/kubernetes/) or a similar tool to ship logs to another service or a third-party platform.
scheduler:report [<app>] [<flag>] # Displays a scheduler report for one or more apps
scheduler:set <app> <key> (<value>) # Set or clear a scheduler property for an app
```
Schedulers are a way of customizing how an app image is deployed, and can be used to interact with non-local systems such as Kubernetes and Nomad.
## Usage
### Scheduler selection
Dokku supports the following built-in schedulers:
-`scheduler-docker-local`: Schedules apps against the local docker socket and runs containers directly on the Dokku host. See the [docker-local scheduler documentation](/docs/deployment/schedulers/docker-local.md) for more information on how this scheduler functions.
-`scheduler-null`: Does nothing during the scheduler phase. See the [null scheduler documentation](/docs/deployment/schedulers/null.md) for more information on how this scheduler functions.
See the [alternate schedulers documentation](/docs/deployment/schedulers/alternate-schedulers.md) for more information on other scheduler plugins.
### Overriding the auto-selected scheduler
If desired, the scheduler can be specified via the `scheduler:set` command by speifying a value for `selected`. The selected scheduler will always be used.
The default value may be set by passing an empty value for the option:
```shell
dokku scheduler:set node-js-app selected
```
The `selected` property can also be set globally. The global default is an empty string, and auto-detection will be performed when no value is set per-app or globally.
-`run`: starts one-off run containers (detached and non-detached) as well as listing run processes
- triggers: scheduler-run, scheduler-run-list
-`ps:stop`: stops app processes
- triggers: scheduler-stop
-`ps:inspect`: outputs inspect output for processes in an app
- triggers: scheduler-inspect
Schedulers may decide to omit some functionality here, or use plugin triggers to supplement config with information from other plugins. Additionally, a scheduler may implement other triggers in order handle any extra processes needed during a deploy.
Schedulers can use any tools available on the system to build the docker image, and may even be used to interact with off-server systems. The only current requirement is that the scheduler must have access to the image built in the build phase. If this is not the case, the registry plugin can be used to push the image to a registry that the scheduler software can access.
Deployment tasks are currently executed directly on the primary Dokku server.
@@ -74,6 +74,36 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
# TODO
```
### `app-list`
- Description: Lists all apps in available to the currently logged in user. Optionally disables filtering by user if the first argument is `false`.
- Invoked by:
- Arguments: `$FILTER`
- Example:
```shell
#!/usr/bin/env bash
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
# TODO
```
### `app-json-process-deploy-parallelism`
- Description: Decides the parallelism to use when deploying a given process type. The default is 1 process entry at a type.
- Invoked by: `dokku deploy`
- Arguments: `$APP $PROCESS_TYPE`
- 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)
@@ -346,8 +376,8 @@ curl "http://httpstat.us/200"
> To avoid issues with community plugins, this plugin trigger should be used _only_ for core plugins. Please avoid using this trigger in your own plugins.
- Description: Allows you to modify the contents of an app _after_ it has been extracted from git/tarball but _before_ the image source type is detected.
- Invoked by: `dokku tar:in`, `dokku tar:from` and the `receive-app` plugin trigger
- Description: Allows you to modify the contents of an app _after_ it has been extracted from git but _before_ the image source type is detected.
- Invoked by: The `receive-app` plugin trigger
- Arguments: `$APP``$TMP_WORK_DIR``$REV`
- Example:
@@ -418,7 +448,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
- Description: Allows you to modify the contents of an app _after_ it has been extracted from git/tarball but _before_ the image source type is detected.
- Invoked by: `dokku tar:in`, `dokku tar:from` and the `receive-app` plugin trigger
- Description: Allows you to modify the contents of an app _after_ it has been extracted from git but _before_ the image source type is detected.
docker tag -f $IMAGE_ID$DOCKER_HUB_USER/$APP:$IMAGE_TAG
docker push $DOCKER_HUB_USER/$APP:$IMAGE_TAG
```
### `tags-destroy`
- Description: Allows you to run commands once a tag for an app image has been removed
- Invoked by: `dokku tags:destroy`
- Arguments: `$APP $IMAGE_TAG`
- Example:
```shell
#!/usr/bin/env bash
# Remove an image tag from docker hub
set -eo pipefail;[[$DOKKU_TRACE]]&&set -x
APP="$1";IMAGE_TAG="$2"
# some code to remove a docker hub tag because it's not implemented in the CLI...
```
### `uninstall`
@@ -2385,3 +2396,44 @@ shift 2
[["$SSH_NAME"=="default"&&$1== plugin:* ]]&&exit1
exit0
```
### `user-auth-app`
This is a special plugin trigger that is executed when listing apps or checking if an app exists. All Dokku commands should check if an app exists at least once before interacting with them so as not to circumvent the check.
Note that the trigger should exit `0`, and each non-empty line on stdout is captured as a valid app name.
The `SSH_USER` is the original ssh user. If you are running remote commands, this user will typically be `dokku`, and as such should not be trusted when checking permissions. If you are connected via ssh as a different user who then invokes `dokku`, the value of this variable will be that user's name (`root`, `myuser`, etc.).
The `SSH_NAME` is the `NAME` variable set via the `sshcommand acl-add` command. For reference, the following command can be run as the root user to specify a specific `NAME` for a given ssh key:
```shell
sshcommand acl-add dokku NAME < $PATH_TO_SSH_KEY
```
Note that the `NAME` value is set at the first ssh key match. If an ssh key is set in the `/home/dokku/.ssh/authorized_keys` multiple times, the first match will decide the value.
- Description: Allows you to deny access to a Dokku app by either ssh user or associated ssh-command NAME user.
- Invoked by: `dokku`
- Arguments: `$SSH_USER $SSH_NAME $DOKKU_COMMAND`
- Example:
```shell
#!/usr/bin/env bash
# hide any apps with the prefix "admin"
# if the logged in user (SSH_USER) or SSH_NAME is not `root`
Dokku Pro is a commercial offering that provides a familiar Web UI for all common tasks performed by developers. End users can expect an interface that provides various complex cli commands in an intuitive, app-centric manner, quickly speeding up tasks that might otherwise be difficult for new and old users to perform. Additionally, it provides a way to perform these tasks remotely via a json api, enabling easier, audited remote management of servers. Finally, Dokku Pro provides an alternative, https-based method for deploying code which can be used in environments that lockdown ssh access to servers.
## Purchasing
Dokku Pro may be purchased online by clicking the following purchase link:
> Currently, the server must be able to contact the public internet to validate the license, or it will fail to start. For offline support, inquire for enterprise offline licensing.
## Installation
Dokku Pro is shipped as Debian and RPM packages, and depends on the following files:
-`/etc/default/dokku-pro`: Configures certain environment variables for usage by the dokku-pro binary
-`/etc/dokku-pro/license.key`: Contains the downloaded license key
-`/var/lib/dokku/data/pro/db`: Contains the local dokku-pro database
Please refer to the purchase email for details on configuring Dokku Pro.
## Features and Development
Dokku Pro has the following functionality:
- Shipped as a single binary for ease of use
- JSON-API-compatible API with JWT authentication
- Authenticated HTTP(S) endpoints for git push functionality
- Single Page App (SPA) Web UI exposing app, datastore, and ssh key management
While each release is fairly feature complete, individual features and documentation will expand over time. Feature development follows a monthly release cadence, with individual bug fixes released on an as needed basis.
For various reasons, certain hosting providers may have other steps that should be preferred to the above. If hosted on any of the following popular hosts, please follow the linked to instructions:
3. You'll be prompted to enter a few parameters, including a unique storage account name and a unique name for the subdomain used for your public IP address. For the `sshKeyData` parameter, copy and paste the contents of the *public* key file you just created. After a few minutes the Dokku instance will be deployed.
4.In your browser of choice, navigate to `http://[dnsNameForPublicIP].[location].cloudapp.azure.com`. Where `[dnsNameForPublicIP]` and `[location]` are template parameters you used to deploy the template.
4.Once the installation is complete, you should configure an ssh key and set your global domain.
5. Finish your Dokku setup like you normally would by creating a *new* public/private key pair for your deployments using `ssh-keygen` (don't use the same one as you created in the first step). You should select **Use Virtual Host Naming** and set the **Hostname** to a *public DNS name* that you own such as one you would purchase from [Namecheap](http://namecheap.com). Alternatively thanks to [sslip.io](https://sslip.io/) you can just use `[yourAzurePublicIP].sslip.io` for free. For example, if your public IP is `44.44.44.44` then you would set it to `44.44.44.44.sslip.io`.
```shell
# usually your key is already available under the current user's `~/.ssh/authorized_keys` file
# you can use any domain you already have access to
# this domain should have an A record or CNAME pointing at your server's IP
dokku domains:set-global dokku.me
# you can also use the ip of your server
dokku domains:set-global 10.0.0.2
# finally, you can use sslip.io to get subdomain support
# as you would with a regular domain name
# this would be done by appending `.sslip.io` to your ip address
dokku domains:set-global 10.0.0.2.sslip.io
```
See the [user management](/docs/deployment/user-management.md#adding-ssh-keys) and [domains documentation](/docs/configuration/domains.md#customizing-hostnames) for more information.
Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice.
Dokku is an extensible, open source Platform as a Service that runs on a single server of your choice. Dokku supports building apps on the fly from a `git push` via either Dockerfile or by auto-detecting the language with Buildpacks, and then starts containers based on your built image. Using technologies such as nginx and cron, Web processes are automatically routed to, while background processes and automated cron tasks are also managed by Dokku.
### System Requirements
To start using Dokku, you'll need a system that meets the following minimum requirements:
- A fresh installation of [Ubuntu 18.04/20.04 x64](https://www.ubuntu.com/download), [Debian 9+ x64](https://www.debian.org/distrib/) or [CentOS 7 x64](https://www.centos.org/download/) *(experimental)* with the FQDN set <sup>[1]</sup>
- At least 1 GB of system memory <sup>[2]</sup>
- A fresh installation of any of the following operating systems:
- A server with one of the following architectures
- AMD64 (alternatively known as `x86_64`), commonly used for Intel cloud servers
- ARMV7 (alternatively known as `armhf`), commonly used for Raspberry PI
- ARMV8 (alternatively known as `arm64`), commonly used for Raspberry PI and AWS Graviton
Dokku is designed for usage on a fresh VM installation, and should install all necessary dependencies if installing via the bootstrap method.
To avoid memory pressure during builds or runtime of your applications, we suggest the following:
- At least 1 GB of system memory
- If your system has less than 1GB of memory, you can use [this workaround](/docs/getting-started/advanced-installation.md#vms-with-less-than-1gb-of-memory).
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.
- Wildcard domain (`*.domain.tld` A Record): will allow access to apps via `$APP.domain.tld`.
- Single domain (`domain.tld` A or CNAME Record): will result in apps being accessed via `domain.tld:$RANDOM_PORT`.
Please see the [dns documentation](/docs/networking/dns.md) and [domains documentation](/docs/configuration/domains.md) for more details.
### Installing the latest stable version
This is the simple method of installing Dokku. For alternative methods of installation, see the [advanced install guide](/docs/getting-started/advanced-installation.md#configuring).
#### 1. Install Dokku
To install the latest stable version of Dokku, you can run the following shell commands:
The installation process takes about 5-10 minutes, depending upon internet connection speed.
If you're using Debian 9+ or Ubuntu 18.04, make sure your package manager is configured to install a sufficiently recent version of nginx<sup>[3]</sup>, otherwise, the installation may fail due to `unmet dependencies` relating nginx.
#### 2. Setup SSH key and Virtualhost Settings
#### 2. Optionally connect a domain to your server
Dokku optionally supports one or more domain names. If you do not own a domain name, you may either purchase one or skip this step.
When connecting a domain, either a single domain or a wildcard may be associated to the server's IP. A wildcard domain will allow access to apps via `$APP.domain.tld`, whereas associating only a single domain name will result in apps being access via `domain.tld:$RANDOM_PORT`. Please see the [dns documentation](/docs/networking/dns.md) and [domains documentation](/docs/configuration/domains.md) for more details.
#### 3. Setup SSH key and Virtualhost Settings
Once the installation is complete, you should configure an ssh key and set your global domain:from-archive
Once the installation is complete, you should configure an ssh key and set your global domain.
```shell
# usually your key is already available under the current user's `~/.ssh/authorized_keys` file
# you can use any domain you already have access to
# this domain should have an A record or CNAME pointing at your server's IP
dokku domains:set-global dokku.me
# you can also use the ip of your server
dokku domains:set-global 10.0.0.2
# finally, you can use sslip.io to get subdomain support
# as you would with a regular domain name
# this would be done by appending `.sslip.io` to your ip address
dokku domains:set-global 10.0.0.2.sslip.io
```
See the [user management](/docs/deployment/user-management.md#adding-ssh-keys) and [domains documentation](/docs/configuration/domains.md#customizing-hostnames) for more information.
Alternatively, instructions for an unattended installation are available in the [advanced install guide](/docs/getting-started/advanced-installation.md#configuring).
#### 3. Deploy your first application
#### 4. Deploy your first application
At this point, you should be able to run or [deploy to the Dokku installation](/docs/deployment/application-deployment.md).
### Installing via other methods
For various reasons, certain hosting providers may have other steps that should be preferred to the above. If hosted on any of the following popular hosts, please follow the linked to instructions:
- [Automated deployment via ansible](https://github.com/dokku/ansible-dokku)
---
- <sup>[1]: To check whether your system has an fqdn set, run `sudo hostname -f`</sup>
- <sup>[2]: If your system has less than 1GB of memory, you can use [this workaround](/docs/getting-started/advanced-installation.md#vms-with-less-than-1gb-of-memory).</sup>
- <sup>[3]: nginx >= 1.8.0 can be installed via the [nginx repositories](https://www.nginx.com/resources/admin-guide/installing-nginx-open-source/), or by adding [this PPA](https://launchpad.net/~nginx/+archive/ubuntu/stable) if you're using Ubuntu. nginx >= 1.11.5 is necessary for HTTP/2 support</sup>
At this point, you should be able to [deploy to the Dokku installation](/docs/deployment/application-deployment.md).
@@ -64,6 +64,25 @@ Save the file and try stopping nginx and starting it again:
## * Starting nginx nginx [ OK ]
```
---
Using the `EXPOSE` directive in a Dockerfile may be another reason why you might see the default site. When the `EXPOSE` directive is in use and a proxy plugin is enabled (the default), the proxy plugin will listen to requests on the ports specified in the `EXPOSE` stanza.
For example, if you have an `EXPOSE` directive like so:
```Dockerfile
EXPOSE8000
```
The proxy port mapping will be `http:8000:8000`.
To avoid this issue, either of the following can be done:
- Remove `EXPOSE` directive: This will require respecting the `$PORT` environment variable (automatically set by Dokku). Once that change is deployed, the port mapping should be cleared via the `dokku proxy:ports-clear $APP` command (where `$APP` is your app name).
- Update the port mapping: Updating the port mapping to redirect port `80` to your app's exposed port via `dokku proxy:ports-set $APP http:80:$EXPOSED_PORT` can also fix the issue. This will also allow certificate management and the letsencrypt plugin to work correctly.
See the [port management documentation](/docs/networking/port-management.md) for more information on how Dokku exposes ports for applications and how you can configure these for your app.
### I want to deploy my app, but while pushing I get the following error
@@ -19,6 +19,9 @@ Docker releases updates periodically to their engine. We recommend reading their
Before upgrading, check the migration guides to get comfortable with new features and prepare your deployment to be upgraded.
- [Upgrading to 0.27](/docs/appendices/0.27.0-migration-guide.md)
- [Upgrading to 0.26](/docs/appendices/0.26.0-migration-guide.md)
- [Upgrading to 0.25](/docs/appendices/0.25.0-migration-guide.md)
- [Upgrading to 0.24](/docs/appendices/0.24.0-migration-guide.md)
- [Upgrading to 0.23](/docs/appendices/0.23.0-migration-guide.md)
- [Upgrading to 0.22](/docs/appendices/0.22.0-migration-guide.md)
@@ -69,16 +72,6 @@ new buildpacks that were released:
dokku ps:rebuild --all
```
> If you have any applications deployed via the `tags` or `tar` commands, do not run the `ps:rebuild --all` command,
> and instead trigger `ps:rebuild` manually for each `git`-deployed application:
>
> ```
> dokku ps:rebuild APP
> ```
>
> Please see the [images documentation](/docs/deployment/methods/images.md) and [tar documentation](/docs/deployment/methods/tar.md)
> for instructions on rebuilding applications deployed by those plugins.
## Upgrading using `dokku-update`
We provide a helpful binary called `dokku-update`. This is a recommended package that:
@@ -87,7 +80,8 @@ We provide a helpful binary called `dokku-update`. This is a recommended package
- Automates many of the upgrade instructions for you.
- Provides a clean way for us to further enhance the upgrade process in the future.
When installing from source, this is available from `contrib/dokku-update`, and is also available on Debian and RPM-based systems from our package repositories under the name `dokku-update`.
This binary is available on Debian and RPM-based systems from our package repositories under the name `dokku-update`. When installing from source,
this is available from a separate Github repository at [dokku/dokku-update](https://github.com/dokku/dokku-update).
## Upgrading using `apt`
@@ -125,6 +119,5 @@ To upgrade Herokuish from source, upgrade with:
@@ -22,7 +22,17 @@ GitHub Discussions is a new way for the Dokku community to interact with each ot
- [Gliderlabs Slack](https://glider-slackin.herokuapp.com/) (Join the `#dokku` channel)
If you’re stumped, give us a holler in the Dokku Slack channel. Someone from the development team is usually there, especially during the daylight hours for North and South American users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate your brand new sports car.
If you’re stumped, give us a holler in the Dokku Slack channel. Someone from the development team is usually there, especially during the daylight hours for North and South American users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate our brand new sports car.
Chat is synced to Discord and IRC.
## Discord
- [Dokku Discord](https://discord.gg/YQjANGMZvu)
We provide a Dokku Discord that folks can use to ask questions or comments about the project. Someone from the development team is usually there, especially during the daylight hours for North and South American users. Feel free to join us online!
Chat is synced to IRC and Slack.
## Unmonitored Locations
@@ -38,4 +48,4 @@ Tag your questions with `dokku` to enable existing users of Stack Overflow to fi
@@ -15,6 +15,8 @@ In Dokku 0.5.0, port proxying was decoupled from the `nginx-vhosts` plugin into
## Usage
> Warning: Mapping alternative ports may conflict with the active firewall installed on your server or hosting provider. Such software includes - but is not limited to - AWS Security Groups, iptables, and UFW. Please consult the documentation for those softwares as applicable.
>
> Users should also avoid setting the `PORT` environment variable. Dokku will use port mappings to set this value. Overriding this manually may cause issues in application routing.
proxy:build-config [--parallel count] [--all|<app>] # (Re)builds config for given app
proxy:clear-config [--all|<app>] # Clears config for given app
proxy:disable [--parallel count] [--all|<app>] # Disable proxy for app
proxy:enable [--parallel count] [--all|<app>] # Enable proxy for app
proxy:report [<app>] [<flag>] # Displays a proxy report for one or more apps
@@ -40,6 +41,24 @@ Finally, the number of parallel workers may be automatically set to the number o
dokku proxy:build-config --all --parallel -1
```
### Clearing the generated proxy config
> New as of 0.27.0
Generated proxy configurations can also be cleared using the `proxy:clear-config` command.
```shell
dokku proxy:clear-config node-js-app
```
All apps may have their proxy config cleared by using the `--all` flag.
```shell
dokku proxy:clear-config --all
```
Clearing a proxy configuration has different effects depending on the proxy plugin in use. Consul the documentation for your proxy implementation for further details.
@@ -11,14 +11,26 @@ enter <app> [<container-type> || --container-id <container-id>] # Connect to a
The `enter` command can be used to enter a running container. The following variations of the command exist:
```shell
# enter the web process
dokku enter node-js-app web
# enter the first web process
dokku enter node-js-app web.1
# enter a process for an app by container ID
dokku enter node-js-app --container-id ID
```
The `container-type` argument can be one either:
- If your app has a `Procfile`, the name of a process type in your `Procfile`.
- If your app has no `Procfile`, the word `web`.
If the specified process type is scaled up to more than one container, then the first container will be automatically selected. this can be overriden by specifying an integer index denoting the desired container, where the first container's index is `1`.
Additionally, the `enter` command can be executed with no `<container-type>`. If only a single `<container-type>` is defined in the app's Procfile, executing `enter` will drop the terminal into the only running container. This behavior is not supported when specifying a custom command; as described below.
By default, it runs a `/bin/bash`, but can also be used to run a custom command:
By default, `dokku enter` will run a `/bin/bash`, but can also be used to run custom commands:
dokku run --env "NODE_ENV=development" --env "PATH=/custom/path" node-js-app npm run mytask
```
One off containers are removed at the end of process execution.
#### Running Procfile commands
The `run` command can also be used to run a command defined in the app `Procfile`:
@@ -59,7 +61,7 @@ dokku run --no-tty node-js-app ls -lah
> New as of 0.25.0
Finally, a container can be run in "detached" mode via the `run:detached` Dokku command. Running a process in detached mode will immediately return a `CONTAINER_ID`. It is up to the user to then further manage this container in whatever manner they see fit, as Dokku will *not* automatically terminate the container.
Finally, a container can be run in "detached" mode via the `run:detached` Dokku command. Running a process in detached mode will immediately return a `CONTAINER_ID`. Detached containers are run without a tty and are also removed at the end of process execution.
ps:inspect <app> # Displays a sanitized version of docker inspect for an app
ps:rebuild [--parallel count] [--all|<app>] # Rebuilds an app from source
ps:report [<app>] [<flag>] # Displays a process report for one or more apps
ps:restart [--parallel count] [--all|<app>] # Restart an app
ps:restart [--parallel count] [--all|<app>] [<process-name>] # Restart an app
ps:restore [<app>] # Start previously running apps e.g. after reboot
ps:scale [--skip-deploy] <app> <proc>=<count> [<proc>=<count>...] # Get/Set how many instances of a given process to run
ps:set <app> <key> <value> # Set or clear a ps property for an app
@@ -30,9 +30,6 @@ This command will gather all the running container IDs for your app and call `do
### Rebuilding apps
> Warning: This section applies only to git-based deploys, and only works deterministically for these apps. Please see the [images documentation](/docs/deployment/methods/images.md) and [tar documentation](/docs/deployment/methods/tar.md)
> in for more information concerning rebuilding those apps.
It may be useful to rebuild an app at will, such as for commands that do not rebuild an app or when skipping a rebuild after setting multiple config values. For these use cases, the `ps:rebuild` function can be used.
```shell
@@ -67,7 +64,13 @@ An app may be restarted using the `ps:restart` command.
dokku ps:restart node-js-app
```
All apps may be restarted by using the `--all` flag.
A single process type - such as `web` or `worker` - may also be specified. This _does not_ support specifying a given instance of a process type, and only supports restarting all instances of that process type.
```shell
dokku ps:restart node-js-app web
```
All apps may be restarted by using the `--all` flag. This flag is incompatible with specifying a process type.
> Using a `formation` key in an `app.json` file disables the ability to use `ps:scale` for scaling.
> Using a `formation` key in an `app.json` file with _any_ `quantity` specified disables the ability to use `ps:scale` for scaling.
An `app.json` file can be committed to the root of the pushed app repository, and must be within the built image artifact in the image's working directory as shown below.
Restart policies have no bearing on server reboot, and Dokku will always attempt to restart your apps at that point unless they were manually stopped.
Dokku also runs `dokku-event-listener` in the background via the system's init service. This monitors container state, performing the following actions:
- If a web process restarts and it's container IP address changes, the app's proxy configuration will be rebuilt.
- If a process within an app exceeds the restart count, the app will be rebuilt.
### Displaying reports for an app
> New as of 0.12.0
@@ -337,3 +345,15 @@ You can pass flags which will output only the value of the specific information
```shell
dokku ps:report node-js-app --deployed
```
### Restoring apps after a server reboot
When a server reboots or Docker is restarted/upgraded, Docker may or may not start old app containers automatically, and may in some cases re-assign container IP addresses. To combat this issue, Dokku uses an init process that triggers `dokku ps:restore` after the Docker daemon is detected as starting. When triggered, the `dokku ps:restore` command will serially (one by one) run the following for each:
- Start all linked services.
- Clear generated proxy configuration files.
- Start the app if it has not been manually stopped.
- If the app containers still exist, they will be started and the generated proxy configuration files will be rebuilt.
- If any of the app containers are missing, the entire app will be rebuilt.
During this time, requests may route to the incorrect app if the assigned IPs correspond to those for other apps. While dokku makes all efforts to avoid this, there may be a few minutes where urls may route to the wrong app. To avoid this, either use a custom proxy plugin or wait a few minutes until the restoration process is complete.
The `app.json` file for a given app can define a special `cron` key that contains a list of commands to run on given schedules. The following is a simple example `app.json` that simply runs the command `npm run send-email` once a day:
The `app.json` file for a given app can define a special `cron` key that contains a list of commands to run on given schedules. The following is a simple example `app.json` that effectively runs the command `dokku run $APP npm run send-email` once a day:
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.