Typebot self-hosting: what the Fair Source chatbot builder actually asks of you

The gap Typebot fills between a form builder and a chat framework

Most teams building a conversational flow end up in one of two places. They wire a chat framework into their own frontend and write every state transition by hand, or they use a hosted form tool and accept its limits on branching and integrations. Typebot targets the space between: a visual editor where you assemble a conversation from blocks, and a runtime that serves that conversation to end users through an embeddable viewer.

The README describes the block set as covering bubbles (text, image or GIF, video, audio, embed), inputs (text, email, phone number, buttons, picture choice, date picker, Stripe payment, file picker), logic (conditional branching, URL redirections, JavaScript scripting, A/B testing) and integrations (webhook or HTTP requests, OpenAI, Google Sheets, Google Analytics, Meta Pixel, Zapier, Make.com, Chatwoot). That is a wide surface for a single tool, and it is the reason the project is not simply a form builder with a chat skin.

The intended audience is explicit in the README: the project says it is "built for developers" and mentions APIs and the absence of vendor lock-in. In practice that means someone who is comfortable running Postgres and Redis, and who wants the conversation definition to live in their own database rather than a vendor's.

Builder, viewer, Postgres and Redis: how the four services relate

The repository ships a docker-compose.yml that defines four services. typebot-db runs postgres:16 with POSTGRES_DB=typebot and POSTGRES_PASSWORD=typebot. typebot-redis runs redis:alpine with a save policy of --save 60 1 and a warning log level. typebot-builder runs baptistearno/typebot-builder:latest and publishes port 8080 on the host, mapped to 3000 in the container. typebot-viewer runs baptistearno/typebot-viewer:latest and publishes 8081 to 3000.

The split matters. The builder is the authoring application where you design a typebot and read results. The viewer is the runtime that serves a published typebot to a visitor. They share the same database and the same Redis instance, and the common anchor block in the Compose file sets REDIS_URL to redis://typebot-redis:6379 for both. Both services declare depends_on with condition: service_healthy for the database and Redis, so Compose waits for the pg_isready and redis-cli ping health checks before starting the applications.

The Dockerfile shows how the images are produced. It pulls Bun from oven/bun:1.3.9-slim, copies the binary into a node:24-bookworm-slim base, installs build-essential, git, g++, openssl and python3, then runs bun install --frozen-lockfile and bunx nx build ${SCOPE}, where SCOPE selects the application. Prisma client generation runs separately with bunx nx db:generate prisma. The release stage copies the Next.js standalone output for that scope and starts it through scripts/${SCOPE}-entrypoint.sh as the node user on port 3000. The monorepo itself is an Nx workspace, with apps/ and packages/ as the top-level directories and a workspace list that includes packages/embeds/*, packages/blocks/* and packages/forge/blocks/*.

Installing Typebot with Docker Compose and opening the builder

The README points self-hosters at the self-hosting installation instructions under docs.typebot.io rather than reproducing them, so the steps below come from the repository's own Compose file and .env.example. Start by creating a .env file next to docker-compose.yml. The example file lists the values you need to set, and the comment above ENCRYPTION_SECRET tells you to replace it with your own random string of 32 characters.

ENCRYPTION_SECRET=do+UspMmB/rewbX2K/rskFmtgGSSZ8Ta
DATABASE_URL=postgresql://postgres:typebot@typebot-db:5432/typebot
NODE_OPTIONS=--no-node-snapshot
NEXTAUTH_URL=
NEXT_PUBLIC_VIEWER_URL=
ADMIN_EMAIL=

Those keys come straight from .env.example. The DATABASE_URL matches the credentials the Compose file gives Postgres, and NODE_OPTIONS is set to --no-node-snapshot in the example. The file also shows a commented WEBHOOK_RELAY_SECRET with a note that it is required when using webhook blocks, that it should be at least 32 characters, and that builder, viewer and the PartyKit server must share it.

With .env in place, bring the stack up from the repository root. The Compose file uses env_file: .env for the two application services, so the variables above reach both containers.

docker compose up -d

Once the health checks pass, the builder is on http://localhost:8080 and the viewer on http://localhost:8081, because the Compose file maps 8080 and 8081 on the host to port 3000 in each container. The README also documents an embed path: the native JavaScript library can mount a typebot as a container, a popup or a chat bubble, and the README claims the embed library uses no iframe and no external dependencies.

The licence is the decision, not the Docker file

The README calls Typebot a Fair Source chatbot builder, and the licence section says the code is protected under a Functional Source License with more information at docs.typebot.io/self-hosting#license-requirements. The repository's LICENSE file is the authoritative text, and the GitHub metadata reports the licence as NOASSERTION, which means the platform could not classify it automatically. A badge in the README references AGPLv3, which conflicts with the Functional Source License named in the licence section, so treat the badge as unreliable and read the LICENSE file.

This is the part of the evaluation that cannot be skipped. A Functional Source License is not an OSI-approved permissive licence, and the README does not restate its terms. What the README does say is that the cloud version's revenue funds maintenance and further development, which frames self-hosting as a supported but secondary path. If your organisation has a policy against non-permissive licences, or if you plan to redistribute a modified Typebot, the licence page is the first thing to read, not the last. Nothing here is legal advice; the point is that this repository's licence is a business decision, not a formality.

On maintenance, the repository is not archived and the last push was on 2026-09-14, the same day as the v3.19.0 release. The two preceding releases, v3.18.0 and v3.17.2, landed on 2026-08-21 and 2026-06-17. That is a steady release cadence over the three months the release list covers.

Where self-hosted Typebot gets awkward

The README lists a long integration set, and WhatsApp is not in it. The integrations named are webhook or HTTP requests, OpenAI, Google Sheets, Google Analytics, Meta Pixel, Zapier, Make.com and Chatwoot. The repository does contain WhatsApp-related test targets, including test-whatsapp-session-access and preview-whatsapp-session-access, which suggests WhatsApp session handling exists somewhere in the codebase, but the README does not document WhatsApp as a supported channel. Anyone whose primary requirement is a WhatsApp bot should verify that path before planning around it.

The second limitation is operational. Self-hosting means you own Postgres backups, Redis persistence and upgrades. The Compose file sets restart: always on every service and gives Redis a save policy of --save 60 1, which writes a snapshot if at least one key changed in sixty seconds. That is a reasonable default and not a backup strategy. The README's own framing is telling: it recommends the managed cloud service as the easiest way to get started, citing high availability, backups, security and maintenance handled by the founder, and says the cloud version "can save a substantial amount of developer time and resources." For a small team, that argument is honest and probably correct.

The third is scope. The Dockerfile builds one application per SCOPE argument, and the Compose file runs two of them. If you want to modify the product, you are working inside an Nx monorepo with workspace globs across packages/*, packages/services/*, packages/embeds/*, packages/blocks/* and packages/forge/blocks/*, plus a Bun lockfile and a Biome config. That is a normal modern TypeScript setup, and it is not a small codebase to take ownership of.

Typebot against a hosted form and survey tool

The closest comparison for many teams is a hosted form or survey product rather than another open source chatbot builder. The difference in approach is where the conversation logic lives and what it can do mid-flow. A hosted form tool generally treats a submission as the unit of work: the respondent fills fields, you receive a row. Branching exists, but it usually stops at showing or hiding questions.

Typebot's model is a conversation with a runtime. The block list in the README includes JavaScript scripting, A/B testing and webhook or HTTP requests as first-class blocks, which means a flow can call out to your own service and branch on the response while the user is still in the conversation. The viewer is a separate deployable from the builder, so the authoring surface and the public runtime can be scaled and exposed differently. The trade-off is that you now run Postgres and Redis, and you own the upgrade path.

Against a self-hosted form tool that stores submissions in the same database, the difference is smaller, and the deciding factor becomes the embed. Typebot's README says the embed library mounts as a container, popup or chat bubble without an iframe and without external dependencies. If your requirement is a conversational widget on an existing site, that is a meaningfully different integration story from an embedded iframe form.

Upgrade cost and what a version bump touches

The repository's package.json sets the root version to 3.19.0, matching the latest release tag, and the release list shows three releases between mid-June and mid-September 2026. Upgrades on the self-hosted path mean pulling new images for baptistearno/typebot-builder and baptistearno/typebot-viewer, and both run Prisma migrations through their entrypoint scripts, since the Dockerfile copies packages/prisma/postgresql and prisma.config.ts into the release stage. The README does not document a rollback procedure, so the practical safeguard is a database backup you take yourself before pulling.

There is a second upgrade consideration that is easy to miss. The Dockerfile pins BUN_VERSION to 1.3.9 as a build argument and builds on node:24-bookworm-slim. If you build your own images rather than pulling the published ones, those two base images are the ones that move when the project updates its toolchain. The Compose file itself references :latest for both application images, which means an unattended docker compose pull will move you forward without a version pin. Pinning to a specific tag is the obvious mitigation, and the release list gives you the tags to pin to.

Editorial conclusion

Adopt Typebot if you want a visual conversation builder you control and you can live with the Functional Source License, which the README points to at docs.typebot.io/self-hosting#license-requirements rather than restating. Do not adopt it if you need a permissive licence, or if WhatsApp is your primary channel, since the README lists no WhatsApp block among the integrations. Before committing, read that licence page, replace ENCRYPTION_SECRET with your own 32-character random string, and confirm which of the two published images your deployment actually needs.

Frequently asked questions

Official sources

1. baptisteArno/typebot.io on GitHub
2. Issues
3. Project website
4. README
5. Releases