Local development

In order to develop on the next-generation platform, your workspace must be on a paid plan.

As you're developing your next-generation app, you can see your changes propagated to your workspace in real-time by using slack run. We refer to the workspace you develop in as your local environment; the workspace you deploy your app to is your deployed environment.

You don't have to deploy your app. In fact, you might never need to slack deploy β€” maybe there's something you want to do just one single time, or only when you need to β€” you can use slack run for that.

But otherwise, you should think of your local environment during slack run as a development environment. We even append the string (local) to the end of your app's name when running in this context.

Using slack run

When you execute slack run from the root directory of a project and you are logged into a Slack Enterprise Grid, you may also be asked to select a workspace within your organization to grant your app access to.

If administrators of your workspace have enabled Admin-Approved Apps, it means your app will need approval before it can be installed to your workspace.

✨ For more information about getting your app approved, check out access controls for developers.

The CLI will then start a local development server and establish a connection to the (local) version of your app. Check that your CLI is logged in to the desired workspace by running slack auth list.

To start the local development server, use the run command:

$ slack run

You'll know your development server is ready when your terminal says the following:

Connected, awaiting events

To turn off the development server, use Ctrl+c.

Note that while you're working in local development mode, no one else will be able to see or interact with your app except for you.

Creating link triggers in local development

Link triggers are unique to each installed version of your app. This means that their "shortcut URLs" will be different across each workspace, as well as between locally run and deployed apps.

When creating a trigger, you must select the workspace that you'd like to create the trigger in. Each workspace has a development version (denoted by (local)), as well as a deployed version.

✨ For more information about link triggers, check out access controls for developers.

If your app has any triggers created within that development environment, they'll be listed when you run slack run. If you only created triggers within a production environment using slack deploy, they will not appear.

Creating triggers with slack run

If you have not used slack triggers create to create a trigger prior to running slack run, you will receive a prompt in the CLI to do so.

Let's say you've created a Slack app and tried to execute slack run without first creating a trigger. The CLI will first ask you which workspace you'd like to run in, and then will prompt you to choose a trigger definition file. If you choose a file, the trigger will be created and the app will run. If you do not choose a trigger definition file or if you do not yet have one created, a trigger will not be created. No worries either way, your app will still continue with the run operation.

Have 2 minutes to provide some feedback?

We'd love to hear about your experience building modular Slack apps. Please complete our short survey so we can use your feedback to improve.