Slack Bot Deployment: Launch a Bolt App on aidrop.it

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Deploy a Slack bot by running its application as a web service, then pointing Slack at the service's HTTPS Request URL. For a first launch, use one slash command that returns a fixed reply. This proves the installed app, request verification, routing, and running deployment work together without adding a database or background jobs.

This walkthrough uses Bolt for JavaScript in HTTP mode and a single Slack workspace. You need permission to install an app in that workspace, a coding agent with Git and a shell, and an aidrop.it Project with room for one Service. Connect the agent through the quickstart.

1. Create the Slack app and save its credentials

Create a separate Slack app for the first deployment and give it only the permissions its demonstration needs. Keep the bot token and signing secret in runtime secrets. The token identifies the installed bot to Slack, while the signing secret allows its HTTP receiver to verify requests before invoking your application code.

Open Your Apps, create an app for the test workspace, and add the commands bot scope under OAuth & Permissions. Install it to the workspace, following any administrator approval requirement. Store the bot token as SLACK_BOT_TOKEN and the Basic Information signing secret as SLACK_SIGNING_SECRET in Project Secrets.

The fixed command response below needs no channel-history permission. Add other scopes only when you add behaviour that requires them, and reinstall when Slack requires approval of changed permissions. Where do the secrets live? explains why the values should stay out of the repository and agent prompt.

2. Build a small HTTP application

Use Bolt's HTTP receiver to handle incoming commands and add a separate health route. Keep request verification enabled. Start with a fixed response that completes immediately, then introduce external API calls or longer work only after the deployment path is proven. An unsigned request to the command route must fail verification.

Have the agent implement GET /health, POST /slack/events, and a handler for /launch-check. Bolt's command guide uses the latter route for slash commands too. The minimal handler is:

app.command('/launch-check', async ({ ack }) => {
  await ack({ text: 'The bot is online.', response_type: 'ephemeral' });
});

Slack requires acknowledgment within three seconds. Keep this response immediate. For later features, acknowledge first and design a durable processing path if accepted work must survive a process restart. Do not log request bodies or response URLs, which can contain sensitive information.

3. Deploy and configure the Request URL

Deploy the application before registering its final Request URL. Verify the health endpoint from outside the container, then use that same origin for the command endpoint. A running process and a working Slack command are separate checks; the second confirms that the workspace configuration actually reaches the deployed handler.

Ask the agent to bind to 0.0.0.0 on the runtime's PORT, use 3000 locally, and push a Dockerfile with locked dependencies. Call service_build with the Project, Service name, repository reference, and:

{
  "build_type": "dockerfile",
  "build_dockerfile_path": "Dockerfile",
  "runtime_kind": "node_http",
  "container_port": 3000,
  "health_path": "/health",
  "required_secret_names": ["SLACK_BOT_TOKEN", "SLACK_SIGNING_SECRET"]
}

Poll service_get; inspect service_logs if it stops. Once the public health request succeeds, open Slash Commands in the Slack app settings. Create /launch-check, set its Request URL to the returned HTTPS origin plus /slack/events, and save. Follow any reinstall prompt. Event subscriptions are unnecessary for this command-only example.

4. Prove the deployed bot answers

Run the command in the installed workspace and check for the expected private reply. Repeat after closing the local development process and after a new application deployment. Those checks distinguish a hosted bot from a local tunnel that happens to be working, and catch settings that were never carried into the deployed runtime.

If Slack reports a timeout, check acknowledgment timing, the exact URL, and runtime logs. For signature failures, follow Slack's request verification guidance; do not disable the check. If the endpoint itself is unreachable, read the runtime before the code.

A deployment brief and verification checklist

Use this brief after creating the Slack app and storing the two runtime secrets. The agent can prepare the code and deploy it, while the workspace owner completes app configuration and sends the first command. Keep the completed checklist in Git with the deployed commit and the intended Request URL.

Deploy a single-workspace Slack Bolt app in Project <project>.
Use HTTP mode, POST /slack/events, and public GET /health.
Read SLACK_BOT_TOKEN and SLACK_SIGNING_SECRET from runtime values.
Keep signature and timestamp verification enabled.
Implement /launch-check with an immediate ephemeral acknowledgment:
"The bot is online."
No database, channel-history access, or event subscriptions needed.
Test health, signed command handling, and rejection of unsigned input.
Build with a Dockerfile, port 3000, and both required secret names.
Push, deploy, and return the commit and HTTPS Request URL.
Do not print credentials, request payloads, or response URLs.

VERIFY
[ ] Public /health succeeds.
[ ] Unsigned requests cannot execute the command.
[ ] Slack's saved Request URL ends in /slack/events.
[ ] /launch-check returns the expected private reply promptly.
[ ] The command works with local development stopped.
[ ] It still works after the next deployment.

FAQ

Does this deployment need Socket Mode? No. This walkthrough receives signed HTTPS requests through Bolt's HTTP receiver. Socket Mode is a different connection method and should be configured as a separate deployment choice.

Do I need a custom domain? No. The public HTTPS address returned by aidrop.it can be used as the slash command's Request URL. Append the application's /slack/events path.

Can I install this version in many workspaces? This example uses one workspace's bot token. Distribution across workspaces requires an installation and OAuth design that stores and selects credentials for the relevant workspace.