Community invitation stack

Stacks/Slack Inviter

Slack Inviter stack

Q: How should I handle CI/CD for buildable services in this stack?

Review the CI/CD page for compatible boilerplates, Git providers, and repository-based pipelines. You can also use the public wodby/wodby-ci repository at https://github.com/wodby/wodby-ci as a starting point or reference. If you prefer your own CI system, run Wodby CLI from https://github.com/wodby/wodby-cli/. It reads your stack information and performs the build, release, and deploy steps for connected services.

Slack Inviter application stack for self-hosting a customizable community invite page with optional Turnstile protection when you already have a working legacy Slack administrator API token.

Legacy Slack token required

Requires an existing Slackin-compatible legacy administrator API token. Slack no longer issues these tokens, and ordinary Slack app or bot tokens do not work. Start a deployment only if you already have a working legacy token.

Start with this stack

Why teams use this stack

Ship faster with ready boilerplates and CI/CD

Build, run post-deployment scripts, and recover through one release workflow.

Keep stack configuration in Git

Version stack.yml and import approved changes as new revisions.

Stay secure with automatic stack maintenance

Control eligible updates and environment maintenance windows.

Monitor and debug running services

Stream logs, inspect metrics, and open a web terminal.

Route traffic through managed endpoints

Use technical routes, custom domains, HTTPS, and published ports.

Reuse one stack across environments

Create development, staging, and production with tailored configuration.

Services

Start with the right services already in place

These services are included with the Slack Inviter stack. The table shows which ones are enabled or disabled by default when you create a new app environment.

Stack services can be configured, added or removed for specific app environments, and their versions can be changed as your workload evolves.

Stack service	Base service	Role
Slack Inviter	Slack Inviter	Primary

Explore the full stack service catalog for configs, settings, actions, cron, volumes, links, backups, and imports attached to each service in this stack.

Deploy

Choose how much infrastructure you want to manage

The application stack stays the same whether you choose Wodby’s managed cloud, infrastructure in your cloud account, or a server you operate yourself.

Wodby Cloud

Start without running a cluster in your own account when you want the most managed option.

Your cloud account

Keep the underlying infrastructure in your own cloud account while Wodby deploys and operates the application stack.

Server or dedicated host

Run the same application stack on a VM, bare-metal server, or dedicated host when that model fits your workload.

Explore hosting options for this stack to compare managed cloud, customer-cloud, and server-based deployment models in more detail.

CI/CD

Start shipping from ready boilerplates and stack-aware CI/CD

Slack Inviter can build from source as part of this stack.

Start from a compatible public boilerplate or connect your own repository from a supported Git provider. External CI and registry integrations still fit the same stack-aware build and release flow.

Release safety

Run post-deploy scripts

Run migrations, cache clears, and other jobs after a successful deployment.

Recover from rollout failures

Try to restore the last successful release when health checks fail.

Restore a previous build

Redeploy an eligible build from history without rebuilding it.

Build rollback restores application images, not stack configuration or persistent data.

Public boilerplates

Slack Inviter

For Slack Inviter

wodby/slack-inviter

Connect your Git repository

BitBucket GitHub GitLab

CI providers

Wodby CIBoilerplates come with a ready pipeline.Circle CI GitHub Actions GitLab Custom CI

Container registries

Wodby Registry Distribution Registry Docker Hub

Explore CI/CD for this stack for boilerplates, Git connections, post-deployment scripts, deployment history, rollback controls, CI providers, and registries.

Routing and endpoints

Publish and control application endpoints

Services in this stack declare the endpoints and ports they can expose. Each app environment can start on default technical domains, then add custom domains, HTTPS, access controls, redirects, or published TCP and UDP ports as needed.

Default technical domains

Reach supported services on generated Wodby domains, then attach custom domains when ready.

Automatic Let's Encrypt HTTPS

Provision and automatically renew trusted certificates for supported public routes.

Authentication and route controls

Protect routes with HTTP basic auth, redirect alternate domains or paths, and tune HSTS, no-index, upload limits, and more.

Explore routing and endpoints to see technical routes, custom domains, managed certificates, route controls, redirects, and published ports.

Private app access

Deploy Slack Inviter behind private access

Choose private app access during app creation to keep every eligible HTTP endpoint behind an approved identity or private network. Protect the complete app, or only admin, staging, dashboard, and other restricted web surfaces.

Cloudflare

View integration

Publish behind a Cloudflare Access identity policy or keep endpoints inside a Cloudflare One private network.

Tailscale

View integration

Give authorized tailnet users and devices stable private HTTPS addresses for the app.

Explore private app access to compare identity-aware access through Cloudflare Access with private-network access through Cloudflare One or Tailscale.

Integrations

Connect and reuse integrations

Attach reusable integrations to the stack so every new app environment starts with the same external connections, variables, and credentials instead of copying values by hand.

That includes product integrations like Algolia, AWS, Anthropic, Auth0, and Cloudflare API, and others.

OpenAI

View integration

Bring API keys and model settings into your apps without scattering secrets.

Anthropic

View integration

Standardize AI credentials once and reuse them across environments.

Intercom

View integration

Manage customer messaging credentials centrally and reuse them across environments.

Sentry

View integration

Attach monitoring variables cleanly to services without editing code.

Stripe

View integration

Keep payment-related secrets controlled and consistent per environment.

Mailchimp

View integration

Keep email marketing keys and audience settings consistent without scattering config.

Explore all integrations for this stack to browse email relays, storage, CI/CD, Git, managed databases, registries, and variable-based providers.

Configuration and customization

Customize services for each environment

Tune the config files and settings exposed by each service without changing its image or rebuilding the stack. Start from the stack defaults, then override only what a particular environment needs.

Slack Inviter

13 settings

Explore configs and settings to see exactly what can be customized for each service in this stack.

Git-managed configuration

Keep your stack configuration in Git

Store the application blueprint in a stack.yml template alongside your code. Version service definitions, defaults, settings, and environment behavior while Wodby turns approved source changes into controlled stack revisions.

Version the application blueprint

Review stack configuration through commits and pull requests before it reaches an environment.

Import updates as new revisions

Follow an approved branch or semantic-version tags without changing running app environments in place.

Keep service updates enabled

Control Git template updates and service auto-updates separately, so customized stacks can still receive eligible releases.

Explore Git-backed stacks and see how they work with automatic updates.

Security and maintenance

Stay secure with automatic service updates

Enable service auto-updates at stack level to pick up eligible security patches and maintenance releases. Wodby creates a new stack revision instead of changing running app environments in place, so every update stays visible and reviewable.

Choose which app environments should auto-upgrade and limit production rollouts to a local-time maintenance window. Development and staging can move sooner while production follows your security and maintenance policy.

Explore automatic updates to see how policies, revisions, maintenance windows, and app environment auto-upgrades work.

Observability and debugging

Understand what running services are doing

Keep the signals and tools for day-to-day troubleshooting close to each app environment, from a quick health check to direct inspection inside a running container.

Stream live container logs

Follow app service output in real time and select a specific workload or container when a service exposes more than one.

Track runtime health

Inspect app environment and service metrics for CPU, memory, storage, readiness, and restarts before changing resources or scaling.

Debug with a web terminal

Open an interactive shell in a running service container for quick inspection and one-off commands without exposing a public SSH port.

Explore observability for logs and metrics, or review service configuration for web terminal access and other runtime operations.

Environments

Create development, staging, and production environments

Launch development, staging, production, or customer-specific environments from the same Slack Inviter stack, then tailor values and configuration to each one.

Start from a consistent baseline

Use the same enabled services and integrations across development, staging, and production.

Customize each environment

Override values, configs, and settings without changing the shared stack definition.

Explore environments for development, staging, and production workflows.

Get started

Create a new Slack Inviter environment

Use the same stack for development, staging, production, and other app environments without rebuilding the definition for each environment.

Start with Wodby

FAQ

Common questions about the Slack Inviter stack

What does the Slack Inviter stack include?

Slack Inviter application stack for self-hosting a customizable community invite page with optional Turnstile protection when you already have a working legacy Slack administrator API token. App environments created from this stack inherit the services enabled by default, attached integrations, hosting options, and stack revision history.

How can one stack support multiple apps and environments?

You can reuse the same stack for multiple similar apps and for development, staging, production, and other environment types. The stack defines the shared services and defaults, you can set different values for env types such as dev and prod, and each app environment can still be configured individually.

How do stack updates work?

When an included service gets an update, the stack can be marked as outdated or create a new revision automatically under its update policy. Existing app environments stay on their current revision until you upgrade them manually or enable stack auto-upgrades with a maintenance window.

How do integrations work with this stack?

Use the Integrations section to attach reusable connections created from supported providers. That keeps credentials, variables, and external services connected to the stack instead of configuring them separately for every app environment.

How should I handle CI/CD for buildable services in this stack?

Review the stack’s CI/CD options for compatible boilerplates, Git providers, and repository-based pipelines, including post-deployment scripts and rollback controls.

You can also use the public wodby/wodby-ci repository as a starting point or reference.

If you prefer your own CI system, run Wodby CLI from GitHub Actions, CircleCI, or similar. It reads your stack information and performs the build, release, and deploy steps for connected services.

Can app environments from this stack run on different infrastructure?

Yes. Development and production app environments from the same stack can run on different hosting models, including Wodby Cloud, managed Kubernetes, and self-hosted Kubernetes on a VM or dedicated server, while keeping the same stack definition and upgrade path.