FormBee: a self-hostable form backend, now without the hosted service

The hosted service is gone, the code is not

The most important line in the README is a notice rather than a feature. The hosted formbee.dev site is now offline as of July 2026, and the repository remains open source for anyone to continue to self host the service.

That changes what this project is. It is no longer a service you sign up for; it is a codebase and a set of container images you run. The distinction matters for anyone evaluating it, because the value proposition in the overview section, an easy way to send form data that is submitted on your website to your email, Telegram, Webhooks and so on, now requires you to operate the thing that does the sending.

The overview explains the model in one paragraph. FormBee is a Form Backend, which means it allows you to have functional forms that send places without having to write any server side code yourself. In practice you embed a form on your site, the submission goes to the FormBee service, and a plugin forwards it to wherever you want it to land.

The project describes itself as the open-source form backend for data privacy conscious developers, and that framing is now the whole point rather than a marketing line. If your reason for using a form service is that you do not want the submissions passing through someone else's infrastructure, then running your own instance is the answer, and the fact that the company that hosted it has stopped hosting it is a reminder of the difference between a product and a project.

The implementation is TypeScript, the licence is MIT, the default branch is main, and the repository is not archived with the last push on 2026-09-20. There are no GitHub releases, and the project calls itself a work in progress passion project.

What a FormBee instance does with a submission

The feature list is short, and each item is a decision about how a public form should behave.

The plugins are the core. Form submissions can be sent to email, Make.com, Telegram, n8n, Discord or webhooks, and the word easily in that list is doing quiet work, because each destination is a different shape of integration and the plugin system is what absorbs the difference between sending an email and posting a structured payload to a workflow automation tool.

Captcha is the second item, and the implementation choice is specific: proof of work captchas. That is a meaningfully different approach from a challenge that asks a human to identify images. A proof of work puzzle costs a client some CPU and asks nothing of a person, which makes it usable on a form that a screen reader user or a mobile client has to submit.

Domain whitelisting is the third, and it is the one that matters most for a self hosted instance. It prevents others from using your form backend by whitelisting the domains that are allowed to submit. On a shared deployment, that is the difference between a service and an open relay that anyone can point at your email or your webhook.

Automatic return emails are the fourth: when someone submits a form, FormBee can send an email back to them automatically, which saves every site owner from writing a second endpoint that says thank you.

The README also says, without irony, that FormBee has more to offer than can be fit in the list, and describes itself as a work in progress passion project. That is a useful calibration for anyone reading the feature list: the items above are the ones the project is willing to commit to in writing.

Self hosting through the docker-images folder

The self hosting story is the strongest part of the project, and it starts from a simple idea: you should not have to run the parts you do not need.

The docker-images folder in the repository contains many variations of the backend you can host, so you can host just what you want without the bloat of the things you do not want. The official self hosting documentation is linked from the README, and it walks through pulling the Docker images and running them with the correct environment variables, after which you can host them wherever you like to host your containers.

The size of the variation is the point. A team that only wants submissions by email does not need the Telegram or webhook integrations resident in the image, and a team that only wants webhooks to an n8n workflow does not need an SMTP configuration. Sizing the image to the destinations is also a mild privacy property, since every additional plugin is another integration that can receive data.

There is a hosted path for the deployment itself. FormBee has official templates on Railway, so self hosting a backend is described as clicking deploy and typing in a few environment variables. The template listed is an Email Only template for hosting just a backend for receiving form data to your email.

That Railway template is the shortest route to a running instance, and the docker-images folder is the general one. Either way, the operational question lands on the person deploying: what data goes where, which destinations are enabled, and who holds the credentials for each one.

Running the monorepo locally

For development, the repository is a monorepo with separate client and server directories, and the README gives instructions for both.

Start by cloning it:

git clone https://github.com/FormBee/FormBee.git

The client side lives under the client directory and uses npm and the Angular CLI:

cd FormBee\client\FormBee
npm install
ng serve

Between installing and serving, there is a configuration step that is easy to miss. You make your way to src/app/global-vars.ts and change fetchUrl to http://localhost:3000, which is how the frontend learns where the backend lives. After that, the client side should be running at localhost:4200.

The server side is the other half, with its own directory, its own environment file and two source edits:

cd FormBee/server/formbee
npm install
cp .env.example .env
npm run dev

You configure the .env with your test database credentials by modifying the DEV_DB variables, and the EMAIL variables configure the email that sends the submission emails. Then you edit src/data-source.ts to comment out the second AppDataSource, the production environment variables, and uncomment the first one, the development variables. And in src/index.ts you change the redirectUrl variable to http://localhost:4200, which the README notes is for CORS.

Three edits for a local run is more setup than a single command would be, and each of them is the kind of thing you only have to do once, but it is the honest cost of a codebase that carries both a production and a development path.

The stack and what it tells you

The tech stack table is short: Angular for the frontend, Node.js with Express for the backend, Postgres with TypeORM for the database, and SCSS and CSS for styling.

That combination is conventional and unremarkable, which is the point for infrastructure software. An Angular client and an Express API with a Postgres database is a stack that a team can hire for, that a hosting provider supports, and that a developer can debug without learning anything unusual.

TypeORM is worth a note. An ORM over Postgres means the data model is defined in the code and migrations are part of the deployment, which is what you want for a service that stores submissions. The alternatives, hand-written SQL or a lighter query builder, would each be defensible, and neither is forced on you by the project.

The repository layout follows the monorepo shape, with a client directory, a server directory, a docker-images directory, a _UsageDemos directory and a single package-lock.json at the root. The presence of a usage demos directory is a small sign of care: a form backend is hard to evaluate from an API description, and a demo page you can click makes the product legible in a way a README cannot.

The project also carries a client subproject named FormBee, matching the repository name, and the topics list includes angularjs, docker, express, form, formsubmission, nodejs, oauth2, open-source and railway. The OAuth2 topic is the one the README does not explain, and it is worth asking about, since a form backend that can authenticate its callers is a meaningfully different thing from one that cannot.

Where FormBee fits, and what to check before you run it

The fit is narrow and clear. FormBee is for a static or simple site that needs a contact form, a signup form or a feedback form, where the owner wants the submissions to land in their own email or their own automation stack, and does not want to write and maintain a server side endpoint for it. Against that need it is a good fit, because the alternative for most teams is either a hosted form service with someone else's data handling, or a small Express project of their own that quietly becomes unmaintained.

The limits follow from the project's own framing. It calls itself a work in progress passion project, and the README says the self hosting image variations are also a work in progress with more being added. That is fine for a side project and not fine for something on a critical path, and you should read the source before trusting it with a production form.

There is no release history to pin to, no GitHub releases, and the only published artefacts are the Docker images and the repository. So there is no supported version matrix, no upgrade path, and no changelog to check for breaking changes. The last push was on 2026-09-20, which tells you the work is still happening, and it tells you nothing about whether a given image matches a given commit.

The captcha and whitelisting features are the parts to test first, because they are the parts with security consequences. A proof of work captcha that can be bypassed leaves your form open to spam, and a domain whitelist that can be worked around leaves your webhook open to anyone. Both are cheap to verify on your own instance before you rely on them.

Finally, the licensing is the simplest part of the decision. The project is licensed under the MIT License, so you can run it, change it, and ship it inside a commercial product without copyleft obligations, keeping the notice. This is not legal advice, and it is one of the reasons this project is easier to adopt than a service with a per-submission price and a data processing agreement.

Editorial conclusion

Adopt FormBee if you want a form backend you can run on your own infrastructure, with plugins for email, Telegram, webhooks and workflow tools, and if a proof of work captcha and domain whitelisting match how you want to protect public forms. Do not adopt it expecting a hosted service, since formbee.dev was taken offline in July 2026 and there is nothing to sign up for. Before you start, read the self hosting documentation and pick the Docker image that matches the destinations you actually need, and if you run it locally, remember that the setup requires you to point the Angular client at the backend, choose the development data source, and set the redirect URL for CORS before the two halves will talk.

Frequently asked questions

Official sources

1. FormBee/FormBee on GitHub
2. Issues
3. License: MIT
4. README