FormTo

Why we open-sourced FormTo (and why AGPL, specifically)

April 5, 2026 · 7 min read

Abstract network pattern — open-source form backend published on GitHub

There's a specific kind of quiet moment in a SaaS company's life when someone on the team asks, for the fifth time that year, "why aren't we open source yet?" Usually it gets deferred. There's always a good reason to wait — "after the next feature," "once we've cleaned up the repo," "once we know what to charge for."

We stopped deferring. The entire FormTo codebase is on GitHub at lumizone/formto, licensed under AGPL-3.0. You can clone it, read it, fork it, and run it on your own server with one docker compose up. Today. No waitlist, no "contact sales," no "enterprise only" fine print.

This post is about why we did it, what it costs us, and why the license we picked is AGPL specifically and not MIT or Apache or BSL.

The short version

Three reasons, in decreasing order of how often we talked about them:

  1. Trust. A form backend handles your leads, your support requests, your customer data. Asking you to trust a black-box vendor with that is a big ask. Asking you to trust a vendor you can read, fork, and audit is a much smaller one.
  2. Data sovereignty. Some users — regulated industries, privacy-focused teams, EU companies with strict DPOs, governments — cannot use cloud form backends at all. For them, "self-hosted" isn't a nice-to-have, it's the only option.
  3. Longevity. SaaS companies die. When a cloud form tool shuts down, its customers have a fire drill. When an open-source project is abandoned, its users can keep running it, fork it, or hand it off to whoever cares enough. The downside risk is fundamentally smaller.

The rest of this post is the long version, because if you're on this page you probably care about the reasoning.

What "open source" actually means for FormTo

Here's what's in the repo:

  • The full backend (Fastify, Node.js 20, postgres.js)
  • The full frontend (React 19, Vite, Tailwind v4, Radix)
  • The database schema and migrations
  • The Docker Compose file that runs the whole thing
  • The Caddy config that terminates TLS automatically
  • The spam detection logic, the honeypot handling, the rate limiter
  • The email template rendering, the webhook dispatch, the Telegram and Slack integrations
  • The analytics page, the CSV/JSON export, the CLI tools
  • The first-run setup wizard

What's not in the repo:

  • Our hosted infrastructure — the EU data centers, the monitoring stack, the on-call rotation, the DPAs with third-party vendors. Those are operational things, not software, and you can't check them into Git.
  • Our commercial contracts, our legal templates, the stuff that's not code.

If you want to run the exact same software that powers our cloud, you can. You'll configure a few environment variables, launch docker compose up -d, and have a form backend running on your own domain within ten minutes. The self-hosting guide walks through every step.

Why AGPL-3.0 and not MIT

This is the license conversation. If you're not interested in license nuance, skip to the next section. If you are, strap in — this is the part of the post that took us weeks to settle internally.

MIT is the most permissive common license. You can do almost anything with MIT-licensed code, including take it closed-source and run it as a commercial product without giving anything back. Tons of great projects use MIT. It has a well-earned reputation as "the friendly license."

Apache 2.0 is similar to MIT but with explicit patent protections. Also very popular.

GPL-3.0 is copyleft — if you distribute a modified version, you must also distribute the source. It's been around since 2007.

AGPL-3.0 is GPL with one critical addition: if you run modified code as a network service, you're considered to have "distributed" it, and you must release your modifications. This closes the so-called "SaaS loophole" where a company can take GPL code, modify it, run it as a hosted service, and never share the improvements.

BSL (Business Source License) is the trendy one right now — source-available but not truly open source under OSI definitions. You can read it, but the license imposes commercial-use restrictions for a period (typically 3–4 years) before the code converts to a real open license.

We picked AGPL for a very specific reason: we want self-hosting to be genuinely free, but we don't want a well-funded competitor to fork FormTo, rebrand it, run it as a hosted service at scale, and give us nothing back.

MIT would allow that. GPL would mostly allow that (the "run as a service" loophole). BSL would explicitly prohibit it but at the cost of not being truly open source, and we didn't want to play the semantic game of calling a not-quite-open license "open source."

AGPL threads the needle. If you want to run FormTo for yourself, your company, your clients — go ahead, no questions asked, that's what the code is there for. If you want to run FormTo as a public commercial service and not release your changes, the license doesn't let you, and we think that's fair.

"But doesn't AGPL scare off users?"

This is the first thing everyone says when we mention AGPL. The folklore is that AGPL is toxic, that corporate lawyers reject it on sight, that you'll lose users.

I think the folklore is out of date. Here's what we've observed so far:

  • Individual developers and small teams don't care about the license at all. They clone, run, ship. AGPL is completely invisible to them because they're not redistributing anything.
  • Mid-sized companies sometimes ask questions, but once you explain that AGPL only kicks in if they modify FormTo and run it as a public service, 95% of the concerns evaporate. Internal use is fine. Use it to process your own forms on your own site — no AGPL obligations trigger.
  • The only group genuinely put off by AGPL is big tech and well-funded competitors who were planning to fork the code and build a paid service on top of it. And that's exactly the group we're trying to discourage.

The "AGPL scares users" narrative was mostly manufactured by companies that wanted to fork AGPL projects without complying with the license. If you're running FormTo on your own server to handle your own forms, AGPL is functionally identical to MIT from your perspective. You don't owe us anything.

What self-hosting gives you that the cloud version doesn't

I want to be honest about the differences, because "we have open source" is a checkbox lots of companies tick without meaning it. Here's what the self-hosted version actually gives you that our cloud version does not:

Total data sovereignty. Your submissions live on your server. Full stop. No third party, no "EU region" claim to verify, no DPAs to sign. If your compliance team needs physical control of the storage, self-hosted is the only option that works.

No submission limits. Cloud plans have tiers. Self-hosted has whatever your server can handle, which is usually orders of magnitude more than most sites need.

Custom integrations without asking permission. Want to add a weird webhook transform? A custom spam heuristic? An internal CRM connector we don't support? Fork the code, edit the file, rebuild. You don't have to file a feature request and wait.

A version of the product that cannot be taken away from you. Even if FormTo shuts down tomorrow (it won't, but theoretically), you still have a working form backend. The code is on your disk, the repo is on GitHub, the database is in your Postgres. You're immune to vendor shutdown risk in a way that cloud users simply are not.

What the cloud version gives you that self-hosting doesn't

To be fair to both directions, here's what you lose when you self-host:

  • Our on-call rotation and 24/7 monitoring
  • Automatic software updates with zero-downtime deploys
  • Our edge network for sub-100ms submission acknowledgment globally
  • Our aggregated reputation data across all customers for spam detection
  • The ability to skip server administration entirely
  • Email deliverability tuning (we run warmed sending domains; you run whatever you configure)

If you're running a personal blog or a small-team internal form, the tradeoffs lean self-hosted. If you're running a marketing site with real traffic and you don't want to be your own sysadmin, cloud is genuinely the better deal. I wrote a longer comparison of the two.

The thing I actually care about

Here's the under-stated reason we went open source, and it's the one I care about most personally.

Every piece of software in my life that I genuinely trust is open source. Not because I read the code (I rarely do). Because I could read the code, and because I know that if I needed to, someone smarter than me already has, and they'd have made noise if something was wrong.

A form backend sits in a trust position. It sees every message your users send you. It decides what's spam and what isn't. It handles email addresses and sometimes phone numbers. If you can't audit it — or hire someone to audit it — you're taking it on faith that the people running the software are good.

I want FormTo to be worth that trust, and I don't want the trust to rely on you liking me personally. The code is on GitHub. Read it. Run it. Ship it. If you find something we got wrong, open an issue or a security advisory. That's the deal.

What this means for the cloud product

People sometimes assume that open-sourcing a SaaS means giving up on the cloud product, or ceding it to self-hosters, or eventually going out of business. Neither of those is what's happening here.

Our cloud product exists because running infrastructure is a full-time job that most people don't want. You can clone the repo and spin up your own FormTo on a VPS — and a lot of people will, and we're delighted by that. Many of those same people will eventually hit a point where they'd rather pay $9/month than run the server themselves, and they'll come back to the hosted version because the software is identical and they already know how it works.

That's a healthy relationship. Self-hosted FormTo is free advertising for hosted FormTo, and hosted FormTo funds the development that self-hosted FormTo benefits from. Both sides win. The economics post has the full breakdown of how the math actually works, because I think transparency about business models is part of the trust conversation too.

Where to start

If this post convinced you and you want to try the self-hosted version:

If this post convinced you and you want to stay on the cloud version: good, that's the version that pays our bills, and the existence of the self-hosted one should make you trust the cloud one a little more.

Either way, thank you for caring about where your form submissions actually live. Most people don't. You're the reason we did this.

Star the repo on GitHub if you like the direction: github.com/lumizone/formto. Issues, PRs, and security advisories all welcome.

More posts

← All posts