The new Slack platform and the features described below are in beta and under active development.

Local development

As you're developing your Run On Slack app, you can see your changes propagated to your workspace in real-time by using slack run.

Actually, you might never need to slack deploy — maybe there's something simple 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 the environment during slack run as a development environment. We even append the string (dev) 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 Run On Slack project, the CLI will start a local development server and establish a connection to the (dev) version of your app in your workspace.

To check which workspace your CLI is logged in to, run slack auth list. The workspace with the ACTIVE label next to it is the one where slack run will run your app.

To turn on 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 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 (dev)), as well as a deployed version.

Listing triggers

When developing locally, you can list the triggers that are associated with your app's workflows by adding --show-triggers to the slack run command, like this:

$ slack run --show-triggers

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

Using environment variables

When developing locally, environment variables present in a .env file at the root of your project will be made available to your custom functions via the env context property.

For example, given the following .env file:

MY_ENV_VAR=asdf1234

We can retrieve the MY_ENV_VAR environment variable from a custom Slack function like this:

// functions/some_function.ts

export default SlackFunction(
  MyFunctionDefinition,
  ({ inputs, env }) => {
    
    const myEnvVar = env['MY_ENV_VAR'];
    
    // ...
  },
);

When you are ready to deploy your application to production, use env add to set environment variables; the .env will not be used when you run slack deploy.

For the above example, we could run the following before deploying our app:

slack env add MY_ENV_VAR asdf1234

Note: if your token contains non-alphanumeric characters, wrap it in quotes like this:

slack env add MY_ENV_VAR "asdf-1234"

Environment variables added with var add will be made available to your deployed app's custom functions via the env context property.

Your environment variables are always encrypted before being stored on our servers, and will be automatically decrypted when you use them—including when listing environment variables with slack var list.

Have 2 minutes to provide some feedback?

We'd love to hear about your experience with the new Slack platform. Please complete our short survey so we can use your feedback to improve.

Next steps