Roadmap
Where Simfra is headed
From Docker-based simulation to Kubernetes-backed networking to full AWS feature parity.
Docker-based simulation
Simfra runs as a single binary with Docker containers for compute and database services. This architecture covers the majority of AWS API behavior but has limitations in networking fidelity.
- ✓88 services, 5,029 operations
- ✓Docker-backed Lambda, RDS, EKS, ElastiCache, MSK, MQ, and more
- ✓Full IAM policy evaluation (identity, resource, SCP, boundary, session)
- ✓Cross-service integrations at runtime
- ✓Multi-account with isolated resource namespaces
- ✓VPC isolation via Docker networks
- ✓Web console, CloudShell, and browser terminal
- ✓SQLite persistence across restarts
Kubernetes hosting environment
Add Kubernetes as an alternative runtime environment alongside Docker. Both are hosting backends for running service workloads — Docker for lightweight local use, Kubernetes for environments that need full network simulation. Simfra selects the backend based on configuration; the AWS API surface is identical regardless of which runtime is active.
- ○Docker and Kubernetes as selectable runtime backends for service containers
- ○Real VPC networking with pod-level network isolation via CNI
- ○Subnet routing, NACLs, and security groups enforced at the network layer
- ○ENI simulation with real IP assignment from subnet CIDRs
- ○NAT Gateway, Internet Gateway, and VPC peering with actual traffic routing
- ○VPC endpoints that route traffic through the cluster network
- ○ELB/ALB/NLB with real pod-to-pod load balancing
AWS feature parity
Comprehensive coverage of all AWS services and operations. The goal is that any Terraform module, CloudFormation template, or SDK application that works against AWS works against Simfra without modification.
- ○Full operation coverage across all implemented services
- ○CloudFormation stack deployment and drift detection
- ○Complete EC2 networking: VPN, Transit Gateway, PrivateLink
- ○Additional database engines: Neptune, QLDB, Timestream, Keyspaces
- ○Analytics services: EMR, Kinesis Data Analytics, Lake Formation
- ○AI/ML services: SageMaker training and inference
- ○Organizations with full SCP inheritance and delegated admin
- ○Control Tower, Service Catalog, and account factory
The networking gap
Today (Docker)
With the Docker runtime, Simfra uses Docker networks for VPC isolation. This provides basic network separation — containers in different VPCs cannot reach each other — but it does not simulate the full AWS networking stack. Subnet routing, NACLs, security group enforcement at the network level, ENI behavior, and traffic routing through gateways are emulated at the API level only. Resources are created and configured correctly, but packets do not actually traverse the simulated network topology. Docker remains the ideal runtime for local development and CI where simplicity and startup speed matter most.
Future (Kubernetes)
With the Kubernetes runtime, Simfra uses CNI plugins and network policies to build a real network topology that mirrors AWS VPC behavior. Each VPC becomes a namespace with its own CIDR range. Subnets get real IP pools. Security groups and NACLs become network policies that filter actual traffic. NAT Gateways, Internet Gateways, and VPC peering connections route real packets between namespaces. This means application code that depends on network reachability, DNS resolution, or specific routing behavior will work the same way it does in AWS. Both runtimes expose the same AWS API surface — the choice is purely about the level of infrastructure fidelity needed.
Want to influence the roadmap?
Tell us what matters most for your use case.