Servlane

The Control Plane for Network Services

Servlane is a modular, Windows-first network services control plane for managing infrastructure services, firewall policy, provider integrations, and hybrid network operations through a unified management layer.

Servlane is designed to coordinate and govern network-facing services without requiring every service to be reimplemented from scratch. Instead, it provides a centralized control layer for native components, third-party software, external systems, and online APIs.

Project Maturity Notice

Servlane is currently in the architecture and foundation stage.

That means:

• Core architectural direction is defined.
• Primary concepts, boundaries, and extension model are being designed.
• Initial runtime, contracts, provider model, and management surface are planned.
• Large parts of the implementation are still incomplete or not yet started.

Servlane should currently be viewed as an emerging platform design and early foundation project, not a production-ready system.

Vision

Modern network environments rarely rely on a single built-in service stack. Real-world operations often involve a mix of:

• Native operating system services
• Third-party infrastructure software
• External appliances and controllers
• Online DNS, certificate, notification, and cloud APIs
• Local, remote, and hybrid operational models

Servlane exists to bring these systems under one safe, auditable, extensible control plane.

The goal is not to replace every service implementation.

The goal is to provide:

• Unified lifecycle management
• Desired-state configuration
• Safe change orchestration
• Provider-based extensibility
• Health, audit, and observability
• Clear separation between control logic and service execution

What Servlane Is

Servlane is a platform that manages and orchestrates network services such as:

• DNS
• DHCP
• Firewall policy
• Certificate automation
• Notifications and webhooks
• Online provider integrations
• External service adapters
• Future hybrid and multi-node operations

In architectural terms, Servlane acts as a control plane.

That means Servlane is responsible for:

• Storing desired state
• Validating configuration
• Coordinating providers
• Applying changes safely
• Monitoring health
• Recording audit events
• Managing rollback and recovery flows

The actual service execution or packet enforcement is delegated to native, external, or online systems.

What Servlane Is Not

Servlane is not intended to be:

• A packet-forwarding engine
• A replacement for every DNS or DHCP server
• A kernel firewall implementation by default
• A monolithic all-in-one network appliance
• A UI-only admin panel without orchestration logic

For example:

• Servlane may manage Windows Firewall or WFP-backed providers
• Servlane may manage CoreDNS, Kea, or Windows DNS
• Servlane may integrate with Cloudflare, Route53, or ACME providers

But those systems remain responsible for actual service execution or enforcement.

Core Principles

1. Control Plane / Data Plane Separation

Servlane controls, validates, and orchestrates.

Providers, operating system components, and integrated services execute.

This separation keeps the architecture safer, cleaner, and easier to evolve.

2. Desired State First

Servlane is designed around desired state rather than one-off imperative actions.

Users define what the system should look like, and Servlane works toward that state through validation, planning, application, verification, and rollback.

3. Capability-Based Provider Model

Servlane should not hard-code every service integration into the core.

Instead, providers advertise capabilities and implement contracts for specific domains such as:

• DNS zone management
• DHCP scope management
• Firewall rule orchestration
• Online certificate automation
• Notification delivery
• Backup targets
• External service lifecycle control

4. Safe Operations by Default

Unsafe configuration changes are one of the biggest risks in infrastructure software.

Servlane is designed to support:

• Validation before apply
• Preview and dry-run flows
• Dependency-aware execution
• Safe apply and verification
• Automatic rollback
• Last-known-good recovery
• Auditability for operational changes

5. Extensible Without Losing Control

Servlane should support native services, third-party software, and online APIs without giving up consistency, policy, or observability.

The platform owns the management model even when service execution is delegated elsewhere.

Architecture Direction

At a high level, Servlane is being designed around the following layers:

Management Clients
- CLI
- Desktop Console
- Web Dashboard
- API Consumers

Management Layer
- API
- Authentication / Authorization
- Audit
- Configuration Store
- Desired State Engine
- Policy Hooks
- Validation / Planning / Apply Pipeline

Runtime Layer
- Runtime Host
- Provider Manager
- Lifecycle Coordination
- Health Monitoring
- Resource Leasing
- Rollback / Recovery Logic

Provider Layer
- Native Providers
- External Service Providers
- Online Providers
- Out-of-Process Providers

Execution Targets
- Windows services
- Third-party daemons
- Windows Firewall / WFP
- Cloud APIs
- Remote services
- External infrastructure systems

## Provider Model

Servlane is built around a provider system.

A provider is responsible for implementing one or more capabilities and exposing them to the platform through a consistent management contract.

### Provider Types

#### Native Provider

A provider implemented specifically for Servlane and integrated closely with the runtime.

Examples:

- Built-in Windows service management
- Native configuration handlers
- Internal platform features

#### External Service Provider

A provider that manages software or services already running on the host or installed by Servlane.

Examples:

- CoreDNS
- Kea DHCP
- FreeRADIUS
- Windows DNS Server
- Windows DHCP Server
- Windows Firewall adapters

#### Online Provider

A provider that integrates with remote APIs or SaaS/cloud systems.

Examples:

- Cloudflare DNS
- AWS Route53
- Azure DNS
- ACME certificate providers
- Slack, Telegram, SMTP, Twilio
- S3-compatible backup targets

#### Out-of-Process or Remote Provider

A provider that runs outside the main runtime boundary and communicates through a defined contract.

This model helps with isolation, language independence, and future provider ecosystem growth.

## Ownership Modes

To support mixed environments, Servlane is expected to support multiple ownership modes:

- `Owned` — Servlane fully owns lifecycle and configuration
- `Managed` — Servlane manages the service but may not have originally installed it
- `Observed` — Servlane monitors and reports, but does not enforce
- `Imported` — existing configuration is brought under Servlane awareness
- `Unmanaged` — explicitly outside Servlane control

This distinction is important for safe adoption in real environments.

## Firewall Direction

Firewall is an important part of the Servlane direction, but it must be handled carefully.

Servlane should treat firewall as a **privileged capability**, not as a casual plugin feature.

The platform should primarily manage:

- Firewall policy
- Rule models
- Validation
- Priority and conflict handling
- Safe apply
- Audit and observability
- Rollback and failover behavior

Actual enforcement should typically happen through established OS or platform mechanisms such as:

- Windows Firewall
- Windows Advanced Firewall rules
- Windows Filtering Platform (WFP)

A custom kernel-level enforcement path should only be considered when there is a strong need for advanced packet handling or inspection.

## Online and Hybrid Integrations

Servlane is intended to support local and online infrastructure together under one model.

Examples of online and hybrid capabilities include:

- DNS record management through public DNS APIs
- ACME certificate issuance and renewal
- Notifications and alert routing
- Backup to object storage
- Threat intelligence and IP reputation feeds
- Overlay network or remote access integrations
- Remote controller and cloud networking hooks

This allows Servlane to evolve into a hybrid infrastructure control layer, not just a local service manager.

## Intended Feature Areas

The long-term direction includes support for:

- Service lifecycle management
- Provider detection and registration
- Configuration translation and rendering
- Drift detection
- Dependency modeling
- Startup and failover policies
- Health checks and diagnostics
- Resource lease management
- Audit events and change history
- Secret references and secure configuration
- Preview / plan / dry-run
- Apply with verification
- Automatic rollback
- Backup and restore
- Migration and import workflows
- Policy hooks and security hardening
- Observability and metrics
- Multi-node readiness
- Provider ecosystem expansion

## Roadmap Direction

Servlane is expected to evolve in additive phases so earlier work does not need destructive redesign.

### Phase 0 — Architectural Foundation

- Core contracts
- Runtime skeleton
- Management API direction
- Configuration model
- Capability and provider contracts
- Audit baseline
- Initial CLI direction

### Phase 1 — Windows Service Runtime

- Windows service hosting
- Startup behavior
- Lifecycle manager
- Basic health checks
- Foundational runtime coordination

### Phase 2 — Native Provider MVP

- Initial provider SDK concepts
- Provider manifests
- Basic native provider support
- Core capability registration

### Phase 3 — External Service Provider Layer

- Third-party service adapters
- Config generation and translation
- Ownership modes
- Drift reporting
- Initial Windows integration paths

### Phase 4 — Safe Change Pipeline

- Validate / plan / preview
- Apply locks
- Verification steps
- Rollback support
- Recovery behavior

### Phase 5 — Management Surfaces

- CLI maturity
- Desktop console
- Web dashboard
- Shared management SDK
- Initial RB DNS API

### Phase 6 — Online Provider Layer

- Cloud and SaaS integrations
- ACME and certificate automation
- DNS API integrations
- Notification providers
- Remote backup targets

### Phase 7+ — Advanced Platform Growth

- Dependency graph execution
- Failover strategy
- Policy engine
- Security hardening
- Observability
- Backup and restore
- Migration tooling
- Multi-node readiness
- Provider ecosystem

## Technology Direction

The current intended technology direction is:

- `.NET` as the main implementation platform
- Windows-first runtime and service model
- `ASP.NET Core` for management APIs
- A dedicated CLI for operations and automation
- Desktop and web management surfaces over time
- Future-compatible contracts for out-of-process providers
- Potential gRPC / Protobuf-based provider communication later

This direction may evolve as implementation progresses.

## Why Windows-First

Servlane is being designed with a strong Windows operational focus because many environments still rely on Windows-native networking, service hosting, policy enforcement, and administrative tooling.

That said, the architectural direction aims to remain extensible enough for hybrid scenarios involving:

- Linux-hosted services
- Online APIs
- Remote appliances
- Cloud-managed infrastructure
- Mixed-provider environments

## Security Direction

Security is a first-class concern in Servlane.

Important design assumptions include:

- Secrets should be referenced, not scattered through raw config
- Privileged capabilities must be explicitly bounded
- Auditability must be built in from the beginning
- Change application must support rollback and verification
- Provider isolation boundaries should be considered early
- Online integrations must respect explicit data-sharing policy

Expected foundational concepts include:

- `SecretRef`
- `AuditEvent`
- `OwnershipMode`
- `HealthStatus`
- `NodeId`
- `PolicyHook`

## Example Direction

A future Servlane workflow may look like this:

1. Define desired DNS, firewall, or provider configuration
2. Validate configuration and capability compatibility
3. Generate a plan
4. Preview intended changes
5. Apply safely with locking and verification
6. Monitor service health
7. Roll back automatically if verification fails
8. Record audit results for traceability

## Who This Project Is For

Servlane is aimed at people building or operating:

- Windows-first infrastructure environments
- Hybrid network service stacks
- Internal platform tooling
- Managed network service layers
- Security-aware operations platforms
- Extensible infrastructure control systems

It is especially relevant when multiple service types and provider models need to be governed consistently.

## Contributing Philosophy

Servlane is intended to grow as a disciplined platform, not just a collection of ad hoc integrations.

That means contributions should generally align with these goals:

- Preserve control-plane consistency
- Avoid bypassing safety and audit flows
- Prefer contracts over hard-coded special cases
- Keep provider integration explicit and observable
- Design for staged evolution rather than rewrite-heavy growth
- Favor operational safety over fragile convenience

As the project matures, contribution guidelines, provider contracts, and architectural decision records should become more formal.

## Current Status

At the moment, Servlane should be understood as:

- A serious platform direction
- An architecture-first foundation effort
- A project with clear scope expansion potential
- A system still early in implementation

If you are looking for a finished production product, Servlane is not there yet.

If you are interested in shaping a modern network services control platform from the foundation up, this is the right stage to follow or contribute.

## Name

**Servlane** is the official project name.

Recommended naming direction:

- Product: `Servlane`
- CLI: `servlane`
- .NET namespaces: `Servlane.*`
- Package and repository naming: `servlane-*` where lowercase is required

## License

License information will be defined by the repository owner.

## Future Documentation

Planned supporting documentation may include:

- `docs/architecture.md`
- `docs/providers.md`
- `docs/security.md`
- `docs/roadmap.md`
- `docs/branding.md`
- `docs/firewall.md`
- `docs/online-providers.md`