Could a "Vercel for Slack apps" work with this CLI?

what would a "vercel for slack apps" look like, using this CLI? is that possible without slack's "authorization"?

today, building and testing and updating a slack app is a bit painful

This is a fascinating question that touches on the architecture and capabilities of the Slack CLI. Let me explore the codebase to understand what's possible and what limitations exist.

Let me dig deeper into the authentication system and how deployments work:

Now let me look at the API calls and authentication mechanisms:

Let me look at the CI/CD documentation and the authentication mechanism more closely:

Now let me look at the hooks system more closely - this is key to understanding what's customizable:

Now let me check the S3 upload and the "remote" hosting mode:

Now I have a good understanding. Let me search for how manifest source remote works:

Now I have a complete picture. Let me provide a comprehensive answer:

##"Vercel for Slack Apps" - Analysis

This is a great question! After exploring the codebase, here's my assessment:

###What the Slack CLI Already Provides

The CLI has strong CI/CD primitives built-in:

1. Service Tokens for CI/CD (slack auth token)

   • Long-lived, non-rotating tokens for automation
   • Can be stored as GitHub secrets (SLACK_SERVICE_TOKEN)
   • Used via slack deploy --token $SLACK_SERVICE_TOKEN

2. Custom Deploy Hooks - The most interesting part for a "Vercel-like" experience:

   {
     "hooks": {
       "deploy": "your-custom-deploy-script.sh"
     }
   }
   

   From docs/reference/hooks/index.md [blocked]:

   "This script is provided by the developer and is meant to simplify app management. There is no restriction on the script."

3. Three Hosting Modes (from internal/shared/types/app_manifest.go):

   • SlackHosted ("slack") - Run on Slack's infrastructure
   • Remote ("remote") - Self-hosted, manifest managed remotely
   • LocallyRun ("local") - Development mode

###The Critical Limitation: Slack's Authorization Gates

Looking at the API layer, everything goes through Slack's servers:

// internal/api/auth.go
const (
    generateAuthTicketMethod = "apps.hosted.generateAuthTicket"
    exchangeAuthTicketMethod = "apps.hosted.exchangeAuthTicket"
    rotateTokenMethod        = "tooling.tokens.rotate"
)

// internal/api/app.go
const (
    appManifestCreateMethod        = "apps.manifest.create"
    appManifestUpdateMethod        = "apps.manifest.update"
    appDeveloperInstallMethod      = "apps.developerInstall"
    appUploadMethod                = "apps.hosted.upload"
    // ...
)

Without Slack authorization, you cannot:

• Create or update app manifests (apps.manifest.create/update)
• Install apps to workspaces (apps.developerInstall)
• Deploy to Slack-hosted infrastructure (apps.hosted.upload)
• Manage triggers, datastores, environment variables

###What You CAN Build: A "Vercel-like" Wrapper

You could build a platform that:

1. Wraps the CLI with your own DX - GitHub Actions already documented in docs/guides/deploying-with-the-slack-cli-and-github-actions.md

2. Uses the deploy hook for custom deployment:

   {
     "hooks": {
       "deploy": "node deploy-to-my-infra.js"
     }
   }
   

   This lets you deploy to your own infrastructure (AWS, GCP, etc.) instead of Slack's hosted runtime.

3. Manages the Bolt framework apps - The Bolt SDKs (JS, Python) use remote function runtime, meaning:

   • You host the actual execution environment
   • Slack just routes events to your endpoint via Socket Mode or HTTP
   • The CLI handles manifest sync and installation

###What Would a "Vercel for Slack" Look Like?

┌─────────────────────────────────────────────────────────────────┐
│                    Your "SlackDeploy" Platform                   │
├─────────────────────────────────────────────────────────────────┤
│  1. git push → triggers build                                    │
│  2. Custom deploy hook → packages your Bolt app                  │
│  3. Deploys to YOUR infra (Lambda, Cloud Run, etc.)              │
│  4. Uses slack CLI with service token to:                        │
│     - Update manifest (apps.manifest.update)                     │
│     - Install/update to workspaces                               │
│     - Configure triggers                                         │
│  5. Your runtime handles events via Socket Mode                  │
└─────────────────────────────────────────────────────────────────┘

###The Key Insight

For Bolt apps (remote function runtime), you're already hosting them yourself. The pain points you're feeling are:

1. Authentication friction - OAuth dance with slackauthticket
2. Manifest management - Keeping api.slack.com/apps in sync
3. Multi-workspace deployment - Installing to many workspaces

A platform could smooth these by:

• Pre-configuring service tokens per org
• Managing manifest source as "remote" (app settings on Slack's side)
• Providing a dashboard for multi-workspace installs

But you cannot bypass Slack's API authorization - every app creation, manifest update, and installation must go through their endpoints. The CLI is essentially a well-designed client for those APIs.

###TL;DR

Yes, possible but limited scope: You can build a better deployment experience around the Slack CLI, but you cannot replace Slack's authorization and app management infrastructure. The hooks system (deploy hook especially) gives you flexibility for where your code runs, but the app registration and installation will always require Slack's blessing.

look at this https://github.com/vercel-partner-solutions/slack-agent-template/tree/main?tab=readme-ov-file

specifically the create a slack app part. is that automatable?

Let me fetch that page to see what they're doing:

Now let me check if there's a Slack API for creating apps programmatically:

Now let me look at the specific API call for apps.manifest.create:

This is very illuminating. Let me check that GitHub issue more closely:

Now I have enough information to give you a comprehensive answer:

##Is "Create a Slack App" Automatable?

Short answer: Partially, but with friction.

Looking at the Vercel template's instructions:

1. Open https://api.slack.com/apps/new and choose "From an app manifest"
2. Choose the workspace you want to use
3. Copy the contents of manifest.json into the text box...
4. Review the configuration and click Create
5. On the Install App tab, click Install to <Workspace_Name>
6. Copy the Bot User OAuth Token into your environment as SLACK_BOT_TOKEN
7. Copy your Signing Secret into your environment as SLACK_SIGNING_SECRET

###What CAN Be Automated

Yes, Slack has an API for this! From the slack-cli codebase:

// internal/api/app.go
const appManifestCreateMethod = "apps.manifest.create"

func (c *Client) CreateApp(ctx context.Context, token string, manifest types.AppManifest, enableDistribution bool) (CreateAppResult, error) {
    // Creates a new Slack app from manifest
}

The relevant Slack APIs:

• apps.manifest.create - Create apps from JSON manifests
• apps.manifest.update - Update existing app configurations
• apps.manifest.delete - Delete apps
• apps.manifest.export - Export app manifests
• apps.manifest.validate - Validate manifests

###The Friction: App Configuration Tokens

The catch: These APIs require an app configuration access token, which:

1. Must be generated manually in the Slack UI at api.slack.com/apps under "Your App Configuration Tokens"
2. Expires every 12 hours
3. Can be refreshed via tooling.tokens.rotate using a refresh token

From a GitHub issue on this exact topic:

"Is it possible to generate an app configuration token programmatically?"

The answer is no - you must generate the initial token manually. However, you CAN rotate it programmatically once you have it.

###What a "Vercel for Slack" Could Do

┌─────────────────────────────────────────────────────────────────────────────┐
│                           ONE-TIME SETUP (Manual)                            │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. User goes to api.slack.com/apps → generates config token + refresh      │
│  2. User stores refresh_token in your platform                               │
└─────────────────────────────────────────────────────────────────────────────┘
                                    ↓
┌─────────────────────────────────────────────────────────────────────────────┐
│                        AUTOMATED FLOW (Your Platform)                        │
├─────────────────────────────────────────────────────────────────────────────┤
│  1. git push → triggers deploy                                               │
│  2. Platform calls tooling.tokens.rotate to get fresh config token           │
│  3. Platform calls apps.manifest.create with manifest.json                   │
│     → Returns: app_id, client_id, client_secret, etc.                        │
│  4. Platform calls apps.developerInstall (or OAuth flow for user)            │
│     → Returns: bot_token, signing_secret                                     │
│  5. Platform stores credentials, deploys your code to Vercel/Lambda/etc.     │
│  6. Platform updates manifest with production URLs                           │
└─────────────────────────────────────────────────────────────────────────────┘

###The Magic URL Trick

Slack also supports a shareable manifest URL:

https://api.slack.com/apps?new_app=1&manifest_json=<URL_ENCODED_MANIFEST>

You could create a "Deploy to Slack" button like:

<a href="https://api.slack.com/apps?new_app=1&manifest_json=%7B%22display_information%22%3A...">
  Create Slack App
</a>

This pre-fills the manifest but still requires the user to click through the UI.

###Bottom Line

The fundamental friction is OAuth consent - a human must authorize the app to be installed in their workspace. Slack won't let you bypass that for security reasons.

###What Would Make This Better

A true "Vercel for Slack" would need:

1. A long-lived config token (not 12-hour expiry) - maybe via the Slack CLI's service token (slack auth token)
2. Pre-authorized workspace relationships - enterprise admins could pre-approve app templates
3. Programmatic OAuth - like GitHub Apps' installation tokens

The Slack CLI's service token approach (slack auth token --no-rotation) is the closest thing to this - it creates a non-expiring token for CI/CD. But it still requires the initial OAuth dance via slackauthticket.