Managed beta.
- Use the complete connected product workflow.
- Managani operates the application and supporting services.
- Updates arrive without maintaining a deployment pipeline.
- Access is capacity-controlled and requests are reviewed weekly.
Hosted beta · AGPLv3 at v1
Open source when Managani leaves beta.
Managani is hosted while we stabilize the complete product with early teams. When beta ends, the application code will be published under AGPLv3 with a documented path to self-hosting.
Public at v1.
Managani is hosted during beta. When beta ends, the complete application repository will be published under AGPLv3 with documented self-hosting. The Node and Express integration SDKs are already public under MIT.
The status today
Hosted now. Public source after beta.
The managed beta is the supported way to use Managani today. This keeps one upgrade path while the data model, installation process, mobile and desktop clients, public surfaces, automation boundaries, and operational defaults are still changing quickly.
AGPLv3 source and self-hosting.
- Inspect and modify the complete application source.
- Deploy on infrastructure your team controls.
- Follow a documented installation and upgrade path.
- Own the network, data location, backups, and operations.
Why AGPLv3
The product loop should not become a permanent cloud-only trap.
Feedback, customer conversations, roadmap history, release communication, onboarding rules, and product events become operating data. Publishing the complete application gives teams a practical route to inspect the system and keep that context close to their own infrastructure.
Inspect the product.
Review how identity, customer context, automation, public surfaces, and data boundaries are implemented before trusting the platform with product history.
Own the deployment.
Run Managani on your infrastructure when data location, internal networking, compliance, or operational policy requires it.
Share modifications.
AGPLv3 is intended to keep network-served modifications available under the same license. Review the published license and source at v1 before deploying a modified version.
What v1 is meant to include
The application, customer surfaces, APIs, and automation.
The planned release covers the connected Managani application rather than presenting public integration packages as if they were the whole product. The intended scope includes the product UI, Widget and Portal, Desktop and Mobile clients, MCP server, REST API, and production deployment configuration.
That scope still requires a stable installation contract. We need repeatable setup, configuration references, upgrades, backups, recovery, mail delivery, search, AI-provider settings, and security guidance before telling teams to run production customer data themselves.
Before the public release
Use the beta to prove the workflow.
A source license does not rescue a product that does not solve the operating problem. Validate the connected loop first.
1
Connect one product.
Identify signed customers and choose a real workflow where context is currently lost between tools.
2
Carry one signal through the loop.
Capture feedback, make a roadmap decision, publish the release, guide the affected users, and review what happened.
3
Tell us what self-hosting must prove.
Use the beta-access form to share infrastructure, security, data-location, upgrade, or integration requirements that should shape the v1 documentation.
Current limitation
The application repository is not public during beta.
Do not plan a production self-hosted deployment today. The public repository, supported installation contract, and release-ready self-hosting documentation arrive when Managani leaves beta.
No ambiguity
“Open source” describes the v1 operating model.
The managed beta is available now. The complete AGPLv3 application and supported self-hosting are planned for v1. The public MIT integration SDKs do not change that distinction.