stackql-registry contains the provider development ecosystem for StackQL. This includes OpenAPI source specifications, provider-specific build and generation tooling, and documentation sites for individual StackQL providers.
🔗 Looking for the main project? The StackQL core project, the published provider registry (deployed using Deno Deploy), client libraries, and GitHub Actions all live in the
stackqlorganisation.
This org houses the upstream source materials and tooling used to build and publish StackQL providers, including OpenAPI source specifications for individual cloud and SaaS providers, provider documentation sites (e.g. provider-specific docs deployed via GitHub Pages), build pipelines and generation scripts for provider definitions, and test suites for provider interface validation.
The published, consumable provider registry that StackQL uses at runtime lives at stackql-provider-registry in the core org.
StackQL providers are defined using OpenAPI specifications with StackQL-specific extensions. The provider development pipeline typically follows this flow:
- Source specs (in this org) — raw or transformed OpenAPI definitions from cloud provider documentation
- Generation tooling (in
stackql) — tools like@stackql/provider-utils - Published registry — the
stackql-provider-registryconsumed bystackqlviaany-sdk
| Organisation | Purpose |
|---|---|
stackql |
Core projects — engine, deploy, registry, client libraries, GitHub Actions. Start here. |
stackql-labs |
Experimental — proof-of-concepts, emerging integrations |
stackql-registry |
Provider development — OpenAPI source specs, build tooling, documentation sites (📍 you are here) |
Interested in adding a new provider or improving an existing one? StackQL's config-file-based provider plugin approach lowers the entry barrier compared to traditional code-intensive plugin frameworks — if a service has an OpenAPI spec, it can become a StackQL provider.
📜 StackQL is released under the MIT License.