Cappio · Identity & platform engineering
A secure, role-based platform with provider-agnostic identity, database-agnostic persistence and revocable sessions behind a cohesive Next.js experience.
01
I founded Cappio to turn operational problems and product requirements into maintainable software that can be deployed and supported in production. Infranet is the clearest expression of that work: a secure platform that gives organisations one identity-aware entry point for administration, internal tools and custom applications.
The project is not only a web interface. It spans product design, application architecture, identity, data, delivery infrastructure and ongoing operation.
02
The platform needed to let capabilities evolve independently without creating separate accounts, duplicated authorization rules or fragmented administration. Browser navigation, server-rendered requests, server actions and direct API clients also needed to share a consistent security model.
That created several constraints:
03
The Next.js application owns the user experience, route protection and administrative workflows. An ASP.NET Core minimal API remains the authority for authentication, authorization and domain operations. Provider and repository boundaries keep external identity and persistence replaceable; the current deployment uses Microsoft Entra and MongoDB adapters.
Keeping identity and policy enforcement behind the API avoids duplicating security decisions in the UI. The communication layer adapts to browser, server-rendered and service-to-service requests without changing those boundaries.
04
External login uses a provider adapter based on established OAuth/OIDC standards. The backend validates the provider response, establishes a protected application session and remains responsible for its validity. Microsoft Entra is the current provider, not a platform dependency.
Users can inspect and close their sessions, while administrators can revoke access through protected workflows. The frontend can query the current identity and session state without becoming the owner of credential validation. Detailed credential and revocation mechanics are intentionally kept out of the public case study.
05
Configurable roles provide understandable access profiles, while fine-grained permissions add the precision required for identity, session and application operations.
The API evaluates those policies on protected endpoints. The Next.js application uses the resulting access context to gate application areas and administrative workflows. The interface can hide unavailable actions, but the backend remains the final authority.
06
Security controls are applied across the identity flow, session lifecycle and protected operations. The design uses layered request validation, browser-request protections, constrained cross-origin access, abuse controls and response hardening. Administrative capabilities are isolated behind backend authorization rather than relying on route visibility.
This public overview deliberately describes the security properties, not the implementation values, validation sequence, credential format or operational configuration.
07
The domain and authentication services depend on repository contracts rather than database-specific APIs. The current MongoDB adapter enforces identity, relationship and lifecycle invariants using database-appropriate constraints and expiry mechanisms. Another persistence adapter can implement the same contracts with its own transaction and lifecycle strategy.
Controlled initialization keeps roles and permissions consistent across environments without relying on manual data-store edits.
08
The automated pipeline validates and builds separate frontend and API images, then promotes them through test and production environments. Container delivery keeps application versions repeatable while environment-specific configuration remains outside the images.
Operational readiness is treated as an application concern: persistence initialization, health checks and environment configuration are part of the deployment contract. Sensitive topology, configuration and recovery details remain private.
09
Using the API as the identity authority creates a clear security boundary, while server rendering and direct API access still need to share a coherent request context. Provider and persistence abstraction add implementation work, but prevent the product's domain model from becoming inseparable from one vendor.
Self-managed containers provide control over persistence and deployment cadence. That control also creates operational responsibility, so resilience and recovery concerns are documented and automated alongside the application without publishing their implementation.
10
I own Infranet from requirements through production: product and system design, Next.js and ASP.NET Core implementation, provider and persistence abstractions, the current Entra and MongoDB adapters, authorization and session security, container networking, CI/CD and operational support. I designed the boundaries and security flows, implemented both sides of the platform and built the delivery path that runs them together.
As founder of Cappio, that ownership extends beyond this single product. I also develop backend services in Go, work with PostgreSQL, and build cloud and Kubernetes environments using Docker, Terraform, Ansible and AWS. The common thread is taking responsibility for the complete system rather than treating application code, infrastructure and operations as separate hand-offs.
11
Infranet is active Cappio work. The platform foundation, identity model and deployment workflow are in place; customer-specific integrations, security internals and operational details remain private. Future work focuses on expanding product capabilities and integration options without weakening the platform boundaries.
Toolkit
Build systems that hold up
