Infrastructure software for controlled connectivity operations.
KARCSHAM builds disciplined operational platforms for service providers and infrastructure teams. KRS delivers radius, tenant-aware access management, and private connectivity in a Dockerized, Caddy-fronted runtime built for real production.
- Runtime
- Dockerized, local-bound
- Ingress
- Caddy, HTTPS terminated
- Connectivity
- WireGuard foundation
- Built for
- ISP and service-provider operations
- Runtime model
- Dockerized, no host Node.js
- Public ingress
- Caddy-only, HTTPS terminated
- Change control
- GitHub source of truth
An operational platform for radius, connectivity, and tenant-aware service delivery.
KRS is built for teams that operate real subscriber networks and service-provider workloads. It puts radius authentication, access governance, and connectivity orchestration on a Dockerized, tenant-aware foundation — without the noise of generic SaaS tooling.
Subscriber authentication and accounting
Radius-centred access for ISPs and managed network providers, with policy and accounting handled as first-class operational data.
Operator and customer access control
Clear separation between operator administration and tenant-level workflows, with predictable controls and audit-ready posture.
Private network and tunnel orchestration
A WireGuard-backed connectivity foundation that lets infrastructure teams reach what they operate without broad public exposure.
Tenant-aware service-provider workflows
Multi-tenant structure with clean administrative boundaries, designed for organizations that run service-provider operations at scale.
Built on disciplined runtime primitives.
KRS is designed against the same constraints real infrastructure teams operate under. The runtime model is explicit, the surface area is small, and every operational assumption is documented.
Dockerized application
The application runs as a Dockerized service through docker-compose. No host-level Node.js is installed on the VPS.
Local bind, no public port
The app binds to 127.0.0.1:3000 only. Application ports are never exposed publicly to the internet.
Caddy-only public ingress
Caddy is the only public entry point. HTTPS is terminated at Caddy, in front of the controlled application surface.
GitHub source of truth
Repository changes flow through normal Git workflow. Deployment changes are explicit, controlled, and requested.
Environment hygiene
Configuration and secrets stay out of the repository. Environment discipline is treated as part of the runtime contract.
Validation before claims
Builds, health checks, and operational behavior are verified locally before any change is declared production-ready.
Secure by architecture, not by promise.
The security posture is enforced by the runtime model. There is no public application port to harden, no host-level Node.js to patch, and no implicit ingress to audit.
No public application port
Application ports are bound to localhost. Public traffic never reaches the application directly.
HTTPS terminated at Caddy
Caddy handles TLS in front of the application. The application stays focused on operational behavior.
Controlled deployment changes
Infrastructure changes are explicit and reviewable. No uncontrolled redesigns of the deployment surface.
Validation-first operations
Each change is built, verified, and observed before being treated as a real production event.
Private connectivity as the operational baseline.
Operator and inter-service reachability run over a WireGuard foundation. Infrastructure teams can reach what they operate without broad public exposure, and connectivity remains a controlled part of the platform — not an afterthought.
- Access model
- Private, authenticated tunnels
- Reachability
- Infrastructure without public exposure
- Operator surface
- Controlled administrative paths
- Baseline
- Connectivity treated as core posture
- 01Operator endpoint
Authenticated WireGuard peer initiates a controlled session.
- 02Caddy edge
Public-facing TLS terminates at Caddy, in front of the runtime.
- 03KRS application
Local-bound application processes operator and tenant context.
- 04Tenant boundary
Tenant-aware logic isolates data and administrative scope.
A multi-tenant model that respects operational boundaries.
KRS is structured so that one platform can serve multiple organizations or customer contexts without collapsing them into a single administrative surface.
Tenant-aware architecture
The platform is organized around tenants as a primary operational unit, not as an afterthought layered on top of a single-tenant core.
Clean administrative scope
Operators and tenants have distinct paths and clear administrative boundaries. Responsibilities and visibility match real-world roles.
Service-provider ready
The tenant model is designed for organizations that serve other organizations — managed network providers, ISPs, and enterprise IT teams.
Evaluate KRS against your operational reality.
KARCSHAM works with infrastructure teams, service providers, and enterprise operators who need disciplined connectivity software. Reach out to discuss fit, deployment, and access.