You Self-Hosted It To Stop Paying. Are You Allowed To?

The automation bill was six hundred and forty dollars a month and it went up again in March, so you did what the tutorial said. Forty minutes, a twelve dollar server, a Docker command copied out of a forum post, and n8n was running on your own box with every workflow that used to be metered now running for nothing. That was a good Friday. Then a client asked whether their onboarding sequence could live on it too, and somebody on your team asked whether that was allowed, and you realized you had never read a single line of the license on the thing your business now runs on.

This question arrives about six weeks after the server goes up, every time. It arrives for the RevOps lead who self-hosted to get out of the engineering queue and now has three departments on it. It arrives harder for anyone who bills clients, because the moment somebody else pays for the output of that server, the answer changes. So here is the answer first.

The answer: the license restricts who you run it for, not where you run it

Self-hosting is not the permission. Self-hosting is a deployment choice, and almost every one of these licenses is completely indifferent to it. What they restrict is purpose, and specifically whether the value is flowing to you or to a third party who is paying you.

Three questions decide your situation, in this order. Who is the output for: your own company, or a customer who pays you for it? Which files did you actually run, because several of these projects ship two licenses in one repository and the second one is not free? And which image did you pull, because in at least one popular case the license you accepted is determined by the Docker tag you typed and nothing else.

For the large majority of operators the answer at the end of those three questions is that you are fine and always were. Running an internal tool on your own server for your own staff is the exact use every one of these licenses was written to permit. If you are a forty person distributor automating your own quote follow ups, stop worrying and go do something useful.

If you are an agency, an MSP, a fractional ops consultancy, or anybody whose invoice includes work that server performs, keep reading, because you are the person the restrictive clause was written about.

What the files actually say

Start with n8n, because it is the one most people self-hosted this year and the one where the gap between the marketing and the license is widest.

The README calls the project fair-code and lists three properties in bold: Source Available, Self-Hostable, Extensible. Under Self-Hostable it says "Deploy anywhere." Read that fast and you have absorbed a promise about freedom that the license does not make. Deploy anywhere is a statement about where. The license is a statement about what for.

The license file itself is the Sustainable Use License version 1.0, and the operative sentence is one line long: "You may use or modify the software only for your own internal business purposes or for non-commercial or personal use." The next sentence closes the obvious workaround: "You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes."

Your own internal business purposes. That phrase is the whole ballgame. An agency running a client's automations on its own n8n instance and billing for the result is not using the software for its own internal business purposes, it is using the software as the delivery mechanism for a commercial service to a third party. Nobody has to sue you for that to be true. It is simply not the license you have.

Two other lines in the same file catch people, and both are above the license text where nobody looks. Files with ".ee." in the filename or ".ee" in the directory name are explicitly carved out and require a separate paid enterprise license, which means a repository you cloned in one command contains code you are not licensed to run. And this one, which I have never seen mentioned in any tutorial: "Content of branches other than the main branch (i.e. 'master') are not licensed." If you built your image from a feature branch to get a fix early, you built from code that carries no license grant at all.

Now put that next to Sentry, which is also source-available, also gets called open source constantly, and lands in a completely different place for the same agency.

Sentry ships under the Functional Source License 1.1, and its restriction is written as an exclusion rather than a permission: "A Permitted Purpose is any purpose other than a Competing Use." A Competing Use means offering the software to others in a commercial product that substitutes for it. Everything else is allowed, and the file then says so explicitly, listing internal use, non-commercial education, non-commercial research, and this fourth item: "in connection with professional services that you provide to a licensee using the Software in accordance with these Terms and Conditions."

Read those two licenses back to back. Both are source-available. Both would sit in the same column of any comparison chart. One of them tells an agency it may not do client work on the software, and the other one tells the same agency, in a numbered list, that professional services for a client who is a licensee are specifically permitted. The category label told you nothing. The file told you everything.

The FSL has one more clause worth knowing about because it changes how you should think about the risk. There is a Grant of Future License at the bottom: an irrevocable additional license under Apache 2.0 that becomes effective "on the second anniversary of the date we make the Software available." The version you are running today becomes genuinely open source in two years, automatically, whether or not the company still wants that. That is a very different bet from a license that can be tightened at the vendor's discretion.

The trap that is not in the license file at all

Metabase is where this gets genuinely sneaky, and it is worth walking through because the same pattern shows up in a dozen other projects.

Metabase's license file splits the repository the way you would expect: AGPL outside the top-level enterprise directory, a commercial license inside it. Fine. But then it says something about the built artifacts that has nothing to do with which files you looked at. Binaries at hub.docker.com/metabase/metabase-enterprise are released under the Metabase Commercial License. Binaries at hub.docker.com/metabase/metabase are released under the AGPL.

Your license is decided by the Docker tag. Not by your intent, not by which features you turned on, not by whether you paid. Somebody on your team pulled the image whose name sounded more capable, because of course they did, and that single character difference in a compose file selected a commercial license for your deployment.

Mattermost does a third version of this. Its license file hands you MIT for the compiled versions the company produces, AGPL or a commercial license for source you compile yourself, and Apache 2.0 for the admin tools and configuration files. Three licenses, one product, and which one applies to you depends on whether you ran their binary or built your own. Activepieces splits by directory: MIT for everything except the packages/ee path, which has its own terms.

None of this is hidden. All of it is in plain text in a file you can read in four minutes. It just is not in the README, and the README is what the tutorial screenshots.

The honest take

I am not a lawyer and this is not legal advice, and I am going to be direct about what the actual risk is anyway, because the vendor-adjacent version of this conversation always overstates it in one direction and the forums always understate it in the other.

Nobody is coming to audit your forty person shop. There is no license police, these companies have no telemetry on your self-hosted box in most cases, and the realistic probability that a violation on an internal server is ever discovered is close to zero. If somebody has told you otherwise they were selling you something.

The exposure is not a lawsuit. It is diligence. It shows up the day a strategic buyer's counsel asks for your software bill of materials, or the day an enterprise customer sends the vendor security questionnaire with a licensing section, or the day you raise and somebody makes a list of every dependency your delivery depends on. At that moment "we run client workloads on a platform whose license permits internal business purposes only" is a finding, and findings get priced. For an agency whose entire service delivery sits on that server, it is not a small finding, because the remedy is either a license negotiation from a position of no leverage or a migration under deal timeline pressure.

The second real cost is that the terms can move. Source-available licenses exist so a vendor can change its mind, and several already have. The version you have today is licensed to you forever under the terms it shipped with, but the next version is licensed however they decide, and you find out at upgrade time. That is a fine trade if you have made it deliberately. It is a bad surprise if you thought you had adopted open source.

Here is the part that annoys people, so I will say it plainly. AGPL is the friendly one for you. Operators have been trained to flinch at AGPL because engineers flinch at it, but the engineer's fear is about shipping a product built on top of it. If you are running Metabase or ToolJet or Documenso as a business tool, unmodified, for your own company, AGPL asks nothing of you at all. The licenses that actually constrain a small business are the polite-sounding ones with names like Sustainable Use, and they are the ones nobody flinches at.

And the fix, when there is one, is usually smaller than the anxiety. The commercial license for the thing you are already running is frequently cheaper than the SaaS bill you left, and it comes with the support contract that you were going to need the first time the server went down at nine on a Sunday. Paying it is not a defeat. It is buying the thing you actually wanted, which was the software without the meter, rather than the thing you accidentally bought, which was an unpriced obligation.

What I would actually do, this week, takes about twenty minutes. Open the LICENSE file in the repository of every self-hosted tool you depend on, not the README and not the pricing page. Search it for the words internal, commercial, and compete. Write down, for each one, whether anybody outside your payroll pays for the output. Where the answer is yes and the license says internal only, you have one decision to make and you now get to make it calmly, on your own schedule, with nobody's counsel in the room.

The tutorial ended at the Docker command because the tutorial was about getting it running. Getting it running was never the hard part.