Overview#
The Pluggable Infrastructure module provides a deployment abstraction layer that allows the platform to run on different cloud and infrastructure environments without changes to application code. Rather than binding services directly to specific cloud primitives, a particular object storage service, a specific queue implementation, or a named AI provider, all infrastructure calls go through a common adapter interface. The appropriate implementation for each primitive is resolved at runtime based on the target deployment configuration, so organisations can select sovereign, on-premise, or hyperscaler backends through configuration rather than redevelopment.
Cloudflare-oriented and Google Cloud Platform (GCP) adapter entries exist for configuration compatibility with customer and partner environments. They are not described here as the platform's current live deploy targets for authentication, web applications, responder mobile, or platform APIs. GCP adapters in particular are configuration-only for compatibility; they do not imply active GCP budget, spend, or workloads on the Knogin side.
This capability is particularly relevant for defence and public sector customers who cannot deploy to hyperscale public cloud and require on-premise or private cloud deployments, as well as multi-national organisations that need to run the platform under different data sovereignty regimes.
Key Features#
- Deployment Target Configuration: Supported configuration targets include
aws(Amazon Web Services),generic(any standards-compatible infrastructure),tactical-edge(air-gapped or limited-connectivity environments), pluscloudflareandgcpadapter families kept for configuration compatibility rather than as stated current live deploy targets - Adapter Registry: A central registry maps each combination of deployment target and infrastructure primitive to the correct factory function, resolving the right implementation at service startup without conditional logic scattered across application code
- Storage Abstraction: Object storage operations (upload, download, list, delete) are fulfilled by the appropriate provider for the target: secure object storage, Amazon S3, Google Cloud Storage (compatibility path), S3-compatible endpoints, or MinIO for tactical-edge deployments
- Key-Value State Abstraction: Ephemeral and session state operations are fulfilled by the registered adapter for the selected target (for example DynamoDB, Redis, Memorystore, or an edge KV adapter when that target is configured)
- Queue Abstraction: Async message publishing and consumption uses the registered queue adapter for the selected target (for example SQS, RabbitMQ, Kafka, Pub/Sub, or an edge queue adapter when configured)
- AI Provider Abstraction: AI inference calls are routed to the configured provider endpoint, a hyperscaler AI service, or a self-hosted model endpoint for environments that require on-premise inference
- Per-Tenant Deployment Configuration: In multi-organisation deployments, each tenant can be assigned a different deployment target, enabling a single platform instance to serve cloud tenants and on-premise tenants simultaneously
- Graceful Adapter Fallback: If no adapter is registered for a specific target and primitive combination, the system falls back to a registered default implementation, ensuring graceful degradation rather than hard failure
- Air-Gapped Tactical Edge Support: The
tactical-edgetarget uses MinIO for object storage, Redis for state, and RabbitMQ or Kafka for queuing, providing a complete, network-independent infrastructure stack for deployments in disconnected or bandwidth-constrained environments
Use Cases#
Public Sector On-Premise Deployment#
A national defence agency cannot use public cloud services for classified workloads. The platform is deployed to the agency's private data centre using the tactical-edge target with MinIO, Redis, and RabbitMQ. Application teams write code once; infrastructure substitution is handled entirely by the adapter layer.
Multi-Region Data Sovereignty Compliance#
A multi-national organisation must ensure that data for EU users remains on EU infrastructure and data for US users remains on US infrastructure. Each tenant is assigned its own deployment target pointing to the appropriate regional provider and storage bucket, with the adapter layer handling routing transparently.
Hyperscaler Migration Without Application Rewrites#
An organisation decides to move backend processing from one supported adapter family to another (for example from a compatibility edge configuration to AWS Lambda and related AWS primitives). The infrastructure team registers the destination adapters in the deployment configuration and switches the target. Application code is unchanged; the adapter registry resolves storage, queue, and AI calls to the new equivalents.
Mixed Connected and Disconnected Units#
A public safety organisation runs connected dispatch centres on its chosen cloud or private infrastructure and deploys the same platform to field command posts that operate in radio-degraded environments. Field command posts use the tactical-edge target; the central dispatch uses the organisation's configured production target. Both run identical application code with infrastructure behaviour determined by configuration at each deployment site.
Self-Hosted AI Inference#
An organisation with data handling restrictions that preclude sending data to external AI APIs deploys a self-hosted inference server and configures the AI adapter to route all AI calls to the internal endpoint. The rest of the application layer is unaware of the substitution.
How It Works#
Supported Deployment Targets#
- aws: Amazon S3, DynamoDB, SQS, Bedrock
- generic: Redis, S3-compatible object storage, standard AMQP or Kafka queues
- tactical-edge: MinIO, Redis, RabbitMQ or Kafka; operates without external internet dependency
- cloudflare (configuration compatibility): edge Workers-style adapters for R2, KV, Queues, Workers AI, and Durable Objects when a customer or environment requires that contract; not stated as the current live deploy target for authentication, web applications, responder mobile, or platform APIs
- gcp (configuration compatibility only): Google Cloud Storage, Memorystore, Pub/Sub, and Vertex AI adapter stubs for environments that must keep GCP-shaped configuration; not used for live Knogin GCP workloads, budget, or spend
Integration#
The Pluggable Infrastructure layer operates beneath all platform services and is transparent to application-layer code. Deployment target selection is set through environment configuration at deployment time, with per-tenant overrides available through the administration console for multi-tenant deployments. Adapters for each target are registered at application startup; adding a new deployment target requires implementing the adapter interface for the required primitives and registering the factory functions, no changes to application service code are required.
Open Standards#
- Amazon S3 API (de-facto object storage standard): All object storage adapters, secure object storage, Amazon S3, Google Cloud Storage (compatibility path), and MinIO for tactical-edge deployments, expose and consume the S3-compatible published service interface, meaning a single boto3-based client works across every deployment target without modification.
- AMQP 0-9-1: The RabbitMQ queue adapter, available for the generic and tactical-edge deployment targets, implements the Advanced Message Queuing Protocol 0-9-1, providing a vendor-neutral wire protocol for asynchronous message exchange in disconnected or on-premise environments.
- Apache Kafka protocol: The Kafka queue adapter, surfaced via dedicated client in the platform, implements the Kafka binary protocol for high-throughput event streaming, enabling the same application queue interface to back either RabbitMQ or Kafka without code changes.
- OpenTelemetry (OTLP): Distributed tracing is initialised at application startup across all deployment targets using the OpenTelemetry developer toolkit; when an OTLP endpoint is configured, spans are exported via the OTLP/HTTP exporter, making telemetry data portable to any OpenTelemetry-compatible backend.
- Prometheus exposition format: A
/metricsendpoint is mounted on the middleware process regardless of deployment target, emitting metrics in the Prometheus text exposition format so that any Prometheus-compatible scraper can collect operational data from cloud, on-premise, or tactical-edge deployments. - OpenAPI 3.x: The platform control-plane published service interface is described as an OpenAPI 3 document, published at a well-known endpoint, allowing operators and automation tooling to discover and interact with infrastructure management operations in a standard, provider-neutral way.
- OAuth 2.0 and JWT Bearer Token: Token-based authentication protects typed, auditable read and write workflows across the platform.