Educational content and glossaries
Voir tous les tags
You've installed STOA. The health check returns 200. Now what?
The gap between "it runs" and "it's production-ready" is where most setups fail. This runbook covers your first 7 days with STOA — the operational habits that prevent 3am surprises, the monitoring that catches issues before your users do, and the hardening steps that separate a demo from a real deployment.
In 2024, HashiCorp switched Terraform from MPL to BSL. In 2023, Redis moved from BSD to SSPL. Elastic, MongoDB, CockroachDB — all followed the same playbook: build community with open source, then change the license when the business needs it.
We understand why they did it. We chose a different path anyway.
STOA Platform is licensed under Apache 2.0 — one of the most permissive open-source licenses that exists. No source-available tricks. No "open core" where the useful features are paywalled. No license change planned for when we hit a revenue target.
Here's why — and why this matters for every developer choosing an open-source API gateway today.
GitOps means your infrastructure is defined in Git and automatically deployed from it. This guide explains what GitOps is, why it matters for solo devs and small teams, and how to start — from versioning config files to full ArgoCD automation.
You know how to git push your code. But what about your infrastructure?
Your Nginx config, your firewall rules, your database credentials, your Kubernetes manifests — where do they live? If the answer involves SSH, a shared Wiki page, or "ask Jean-Michel, he set it up" — you have a problem.
GitOps means treating infrastructure the same way you treat code: versioned, reviewed, auditable, and automatically deployed from a Git repo. No more SSH. No more "works on my machine." No more mystery configs.
GitOps is a core principle of open-source API management — and one of the reasons STOA was designed GitOps-first from day one.
10 practical security steps that take less than a day and prevent 95% of API incidents. No enterprise budget, no complex tooling — just engineering discipline. Covers secrets, rate limiting, CORS, auth, TLS, logging, and dependency management.
You're a freelancer. You shipped an API for a client. It works. Tests pass. Invoice sent.
Six months later, the client calls: someone scraped their entire user database through your API. No rate limiting. No input validation. Default CORS headers. The API key was in the frontend JavaScript.
This happens more often than anyone admits. And it's almost always preventable with a simple checklist. This is part of our open-source API management philosophy: security should be accessible to everyone, not just enterprises.
The API gateway landscape has evolved rapidly with the rise of AI agents, zero-trust architectures, and hybrid deployments. This glossary defines 30 essential terms every developer should know when working with modern API gateways in 2026.
Deleted API keys stay in git history forever. This article shows you how to detect leaked secrets with gitleaks, remove them from history, and prevent future leaks with pre-commit hooks and proper secret management.
You removed the hardcoded API key from your code. You committed the fix. You pushed. You're safe now, right?
No. The key is still in your git history. Anyone with git log -p can find it in seconds.
This isn't a theoretical risk. GitHub scans over 100 million commits per day and finds thousands of valid secrets — API keys, database passwords, cloud credentials. Most of them were "removed" by developers who thought deleting the line was enough.
This is one of the most critical security gaps in modern API development — and one of the reasons we built STOA as an open-source API gateway with secrets management as a default, not an add-on.