Self-hosted, not cloud-hosted
More operational responsibility on the operator, but no per-seat licensing, no forced telemetry, and no foreign jurisdiction over identity data.
Projects
Projects and open-source tools
What I am building, what keeps breaking, and what I am learning as the architecture evolves.
Flagship project
Solux
A local-first AI workflow engine that chains inputs, transforms, and local LLM steps into automated pipelines. Everything runs on your machine: no cloud APIs, no vendor lock-in, no data leaving your network.
YAML-defined workflows with 30+ built-in modules, 5 trigger types, CLI and web UI, security modes with RBAC, and MCP server mode for AI agent integration.
Open source project
Butler
An access-control reverse proxy for Ollama. Butler adds multi-user authentication (API keys, JWT, OIDC), per-user model authorization, rate limiting, input filtering, and Prometheus observability, without changing Ollama or your clients.
Single static Go binary, one YAML config file, one external dependency. Fail-closed by design. Supports Keycloak, Okta, and Entra ID out of the box.
Open source project
Porthole
Porthole gives security-conscious Android users a safe, controlled way to authenticate with captive portals (hotel WiFi, airport networks, coffee shops), without compromising their VPN tunnel. It opens an isolated, time-limited browser session that operates outside your VPN, authenticates with the portal, and shuts down cleanly when you're done.
Kotlin. Apache 2.0 licensed.
Open source project
TrueStream
In a world where deepfakes can impersonate anyone on a video call, TrueStream sits quietly in your browser and watches for signs of manipulation. When something looks off, it tells you. When you need certainty, it lets you prove who you are through the Vinsium cryptographic identity protocol.
TypeScript browser extension. Apache 2.0 licensed.
Active project
In development since 2019Keystone
An open-source replacement for Active Directory, Entra ID, Intune, and Always-On VPN. Keystone unifies a directory and Kerberos KDC, single sign-on with MFA, a self-hosted mesh network, and a purpose-built compliance engine into one stack that organisations can audit, modify, and operate without permission.
In development since 2019. The architecture, policy agent, plugin system, GPO conversion pipeline, compliance bridge, and management CLI are functional. Source is not yet public. If you want to follow progress or discuss deployment scenarios, reach out through the contact page.
Why I am building this
Identity, device compliance, and network access are foundational to every IT operation, and they should not depend on a single vendor's cloud, pricing model, or geopolitical jurisdiction. Keystone delivers the capabilities enterprises expect from the Microsoft ecosystem while keeping every byte of data under the operator's control.
What I am learning
The hard problems are not the directory or the VPN: they are making Kerberos ergonomic, translating Windows policy semantics to Linux without losing precedence, and proving compliance verdicts in a way that auditors and operators both trust.
Current challenges
- Making Kerberos approachable so operators do not need to memorise SPN naming, keytab rotation, and TGS flow to run a working domain.
- Mapping Windows GPO semantics to Linux primitives without losing precedence rules, force flags, and inheritance blocks.
- Proving compliance verdicts are trustworthy: signed reports and audit chains that survive an endpoint compromise.
- Distro matrix coverage: keeping plugins behaving consistently across Ubuntu, Debian, RHEL, and Fedora release cycles.
Architecture decisions and trade-offs
Kerberos for every component
Higher setup complexity than bearer tokens, but inter-component auth uses the mechanism the directory already provides, no parallel secret store to compromise.
Compliance gates network access
Non-compliant endpoints lose mesh-network ACLs to sensitive subnets. Stricter than reporting-only models, but it makes "non-compliant" a real boundary.
Active project
Vinsium
Private AI infrastructure that runs entirely on your network. Vinsium combines zero-trust mesh networking, a local AI workflow engine, and enterprise identity into a single platform with no cloud dependency.
If you want to follow progress or discuss deployment scenarios, reach out through the contact page.
Why I am building this
Organizations that care about data sovereignty need to run AI workloads without sending sensitive data to cloud APIs. Vinsium gives them local LLM inference, composable processing pipelines, and serious security controls without the enterprise overhead.
What I am learning
The hard problems are not the AI models: they are identity federation at the edge, audit chain integrity across distributed nodes, and building operational visibility that operators actually trust.
Current challenges
- Keeping audit chain integrity across distributed mesh nodes while maintaining tamper-evident logging.
- Balancing module sandboxing (trusted vs. untrusted security modes) with workflow flexibility.
- Making operational dashboards actionable rather than decorative: live health checks that map to real security controls.
- Identity provider federation edge cases across Okta, Entra ID, Auth0, and LDAP attribute mapping.
Architecture decisions and trade-offs
Local-only LLM inference
Higher hardware requirements than cloud AI APIs, but sensitive data never leaves the network. No vendor lock-in on model choice.
Composable pipeline modules
29 input/transform/AI/output modules instead of monolithic workflows. More wiring, but each module is independently testable and replaceable.
Tamper-evident audit chains
HMAC-SHA256 chain signing adds write overhead, but gives operators a verifiable, tamper-proof audit trail.
Past project
Mistborn
Mistborn started as a personal experiment in making private networking and self-hosted services easier to run. It grew into a real platform used by builders who care about privacy without enterprise overhead.
How it started
A home-lab project that kept growing because each solved problem exposed the next frustrating one.
What went wrong
- Early installers assumed too much and failed on edge cases I did not know existed.
- I made deployment paths too clever in a few places, which made debugging painful for new users.
- I waited too long to simplify docs. Good defaults matter more than long option lists.
What I would do differently
I would optimize for simpler operational paths earlier, and treat docs as a product surface from day one.
Community contributions
- Bug reports that caught real-world DNS and networking edge cases before they became bigger problems.
- Pull requests and issue threads that improved install reliability and service ergonomics.
- Tutorial videos and independent reviews that brought the project to builders I never would have reached alone.
Independent Coverage
Linux Pro Magazine, Awesome Open Source, and DB Tech covered Mistborn. Those early reviews helped shape where the project went next.
- Linux Pro Magazine (Nov 2020)
- Awesome Open Source (Jul 2020)
- DB Tech (May 2021)