DevCloud aims to be a local development companion for cloud-native apps across every major CSP — not a production replacement, but an on-ramp that lets you iterate without cloud bills and deploy to your target CSP with confidence. It gets there in phases, to keep scope, architectural complexity and community expectations manageable.
- Local-first, cost-free — no cloud charges for inner-loop development.
- On-ramp, not replacement — DevCloud helps you land on a CSP, not avoid it.
- API-compatible, not behaviour-perfect — SDK compatibility over edge-case parity.
- Community-owned — the scope is too large for one maintainer, so the plugin architecture and contributor experience are first-class.
- Trademark-respectful — see TRADEMARKS.md.
Mature the already-broad AWS surface into a stable, well-tested v1.0.
- AWS services scaffolded from official Smithy models via in-tree codegen — counts in coverage.md
- Deep hand-written coverage on core and integration services
- Cross-service integration — CloudFormation, DynamoDB Streams → Lambda, SQS → Lambda, S3 → Lambda, EventBridge, SNS → SQS
- boto3 compatibility suite green in CI; a failing test fails the build
- Unimplemented operations return an AWS-shaped error instead of a false
200 - Stable
ServicePluginAPI (plugin-api.md), enforced by a conformance test over every registered service - Generic CRUD fallback engine serving the long tail with plausible, store-backed responses. Follow-up: promote high-value
auto-crudoperations to hand-verified fidelity. - v1.0 release — see compatibility-policy.md
Refactor internally so adding a CSP does not require forking the project. Each item made a future provider an addition rather than an edit — the seams are tabulated in architecture.md.
- Intermediate Representation between models and codegen (
internal/codegen/ir). Generators read*ir.Model; nothing in the IR names Smithy. - Parser refactored behind
ModelSource.SmithySourceowns its own format detection, socmd/codegennever names a format. - Provider namespacing in config —
providers.aws.services.*, forward-compatible withproviders.azure.*(configuration.md). - Plugin interface review —
ServicePluginneeded no change; the CSP is carried by the optionalProviderScoped. - Per-provider auth adapters (
internal/auth).SigV4is the AWS implementation; AAD/SAS and OAuth2 slot in beside it without touching the gateway.
Phase 2 deliberately shipped no non-AWS service, no second ModelSource, and
no signature verification. Those are Phase 3 and beyond; Phase 2's job was to make
each of them an addition rather than a fork.
Validate the multi-CSP architecture with one well-scoped pilot.
- Pick an Azure pilot service — candidate: Azure Blob Storage, closest to S3 semantically
- OpenAPI → IR → codegen proof of concept
- Azure authentication adapter (Shared Key to start)
- Compatibility tests against
azure-sdk-for-python - Documentation pattern for multi-CSP service docs
- More Azure services — Queue Storage, Table Storage, Cosmos DB
- Google Cloud pilot — candidate: Google Cloud Storage
- Other providers as community interest justifies
- Federated identity playground (cross-CSP IAM simulation)
- Production hosting or high-availability guarantees
- Billing and quota simulation matching real CSP pricing
- Exact replication of CSP-internal behaviour (consistency timing, rate limits)
- Redistribution of CSP-owned branding assets, logos or documentation
- Missing service? File a service request with
GET /devcloud/api/unroutedoutput — that is what moves a service into the target (coverage.md). - Missing operation or capability? File a feature request.
- Upvote existing requests with reactions; vote counts inform prioritization.
- Or contribute it — see contributing.md.
| Version | Focus |
|---|---|
| 0.x | AWS services, unstable API |
| 1.x ← current | AWS depth, stable plugin API, multi-CSP groundwork |
| 2.x | Multi-CSP architecture, Azure pilot |
| 3.x+ | Broad CSP coverage, community-owned providers |