Manage your applications using the following commands:
runway app createrunway app showrunway app lsrunway app deployrunway app deploy imagerunway app restartrunway app plan setrunway app registry set/resetrunway app rmrunway app route on/offrunway app lockdown on/offWhen working within your app’s repository, we usually guess the app from the git-remote that we created with runway app create.
If you work outside of this context, all subcommands of runway app support the following flag:
-a--appExamples:
runway app create
runway app create my-app
The app name, if given, must be unique across Runway. If not given, we will chose a random app name.
Creating an application has additional options:
| short version | long version | description |
|---|---|---|
-p |
--plan |
the plan to use |
| n/a | --persistence |
enable persistence |
-r |
--region |
for available locations see runway region ls |
Plus options to inherit config settings from other apps, see below.
All plans are available via runway plan ls or on our website.
You can up- or downgrade your app’s plan at any time. See the plan documentation for details.
By default applications on Runway are using ephemeral disks — each deploy is a brand new environment.
--persistence enables a volume which is mounted at /data. You can use this volume to save data that should be kept across deploys. The caveat is that the volume needs to be released during a deployment, which may cause short blips!
Persistence can be enabled for Scale plans and up. Once enabled, it cannot be disabled.
Worker and init processes do not have access to the /data volume.
Running runway app create ... --inherit-from=my-other-app will copy over
the config values (env vars) and the settings
(routing and lockdown)
from another app.
You need at least viewer permissions on the app you
want to inherit from.
There is also --with-config-from=APP and --with-settings-from=APP to only
do one or the other.
Deploy your app from the local git repository:
runway app deploy
Runway pushes your committed changes to the build pipeline, then starts the new release.
Deploy a pre-built container image directly:
runway app deploy image registry.example.com/myapp:v1.2.3 --app=myapp
Runway reads the exposed port and user from the image metadata (EXPOSE, USER). The USER must be set to a numeric UID.
For images in a private registry, you need to associate that registry with the app first — see runway app registry set.
runway app deploy image. For all other deployments, Runway manages the registry automatically.runway app registry set https://registry.example.com --app=myapp
runway app registry reset --app=myapp
registry set associates a registry (previously added via runway registry add) with the app, so Runway can pull private images from it. registry reset restores the default Runway-managed registry.
See registry for the full credential management workflow.
Restarts the app, applying the latest configuration.
If used as app restart --release=$VERSION, it restarts the app as it was at
the given version. This can be used to revert back to older configurations and/or
builds.
App deletes are soft, unless you use --force:
runway app rm --force --confirm=APP
runway app rm --force --confirm=APP --app=APP
The name of the application is inferred from the the git-remote (called runway) in the current directory.
To delete a specific application:
runway app rm -a APP