For CI/CD pipelines, it may be useful to see if an application exists before creating a "review" application for a specific branch. You can do so via the `apps:exists` command:
```shell
dokku apps:exists node-js-app
```
```
App does not exist
```
The `apps:exists` command will return non-zero if the application does not exist, and zero if it does.
A common pattern for deploying applications to Dokku is to configure an application before deploying it. You can do so via the `apps:create` command:
```shell
dokku apps:create node-js-app
```
```
Creating node-js-app... done
```
Once created, you can configure the application as normal, and deploy the application whenever ready. This is useful for cases where you may wish to do any of the following kinds of tasks:
In some cases, you may need to destroy an application, whether it is because the application is temporary or because it was misconfigured. In these cases, you can use the `apps:destroy` command. Performing any destructive actions in Dokku requires confirmation, and this command will ask for the name of the application being deleted before doing so.
```shell
dokku apps:destroy node-js-app
```
```
! WARNING: Potentially Destructive Action
! This command will destroy node-js-app (including all add-ons).
! To proceed, type "node-js-app"
> node-js-app
Destroying node-js-app (including all add-ons)
```
This will prompt you to verify the application's name before destroying it. You may also use the `--force` flag to circumvent this verification process:
Destroying an application will unlink all linked services and destroy any config related to the application. Note that linked services will retain their data for later use (or removal).
You can rename a deployed app using the `apps:rename` command. Note that the application *must* have been deployed at least once, or the rename will not complete successfully:
```shell
dokku apps:rename node-js-app io-js-app
```
```
Destroying node-js-app (including all add-ons)
-----> Cleaning up...
-----> Building io-js-app from herokuish...
-----> Adding BUILD_ENV to build environment...
-----> Node.js app detected
-----> Creating runtime environment
...
=====> Application deployed:
http://io-js-app.ci.dokku.me
Renaming node-js-app to io-js-app... done
```
This will copy all of your app's contents into a new app directory with the name of your choice, delete your old app, then rebuild the new version of the app and deploy it. All of your config variables, including database urls, will be preserved.
Remember to also change your git remote on your local machine in order to make `git push dokku main` work again. For this you can use `git remote set-url`.
You can clone an existing app using the `apps:clone` command. Note that the application *must* have been deployed at least once, or cloning will not complete successfully:
This will copy all of your app's contents into a new app directory with the name of your choice and then rebuild the new version of the app and deploy it with the following caveats:
- All of your environment variables, including database urls, will be preserved.
- Custom domains are not applied to the new app.
- SSL certificates will not be copied to the new app.
- Port mappings with the scheme `https` and host-port `443` will be skipped.
> If you have exposed specific ports via `docker-options` plugin, or performed anything that cannot be done against multiple applications, `apps:clone` may result in errors.
Finally, if the application already exists, you may wish to ignore errors resulting from attempting to clone over it. To do so, you can use the `--ignore-existing` flag. A warning will be emitted, but the command will return `0`.
If you wish to disable deploying for a period of time, this can be done via deploy locks. Normally, deploy locks exist only for the duration of a deploy so as to avoid deploys from colliding, but a deploy lock can be created by running the `apps:lock` command.
> Removing the deploy lock *will not* stop in progress deploys. At this time, in progress deploys will need to be manually terminated by someone with server access.
In some cases, you may wish to inspect the state of an app lock. To do so, you can issue an `apps:lock` command. This will exit non-zero if there is no app lock in place.