connectforge

Manage a tenant's connections to external services in Go: provider definitions, connections, sealed credentials, grants and bindings, and a broker that hands out authenticated HTTP clients so callers never handle a raw secret.

Pre-release

connectforge has not been externally audited. Version 0.1.0 supports static API-token connections. Read Security first.

What it does

One model for every connection	Provider, connection, credential, grant and binding, with a lifecycle that separates what was decided from what was observed.
Owns the credential lifecycle, not the API clients	Provider SDKs stay in their own modules and receive an authenticated *http.Client through their WithHTTPClient option.
Secrets stay out of sight	Secret redacts itself everywhere it can be printed, errors carry a status and a request ID but never a body, and only the broker and providers can read a value.
Tested connections	A credential is validated with its provider before it is stored, and again on demand. A permanent failure moves the connection to needs_attention.
Ports and adapters	Encryption, authorization, audit, leasing and deployment secrets are interfaces your application supplies.
Restricted egress	A provider's requests reach only the hosts its manifest names, over HTTPS, never a private address.

What it is not

• Not a provider API client. It does not wrap the GitHub, Cloudflare or Stripe APIs.
• Not a cryptography library or a secret manager. Encryption and secret retrieval are ports; use a key-management library such as keyforge and a secret manager such as omnivault.
• Not a workflow engine. A connection can be used by workflows; it is not one.

Where to start

• Getting started connects a service end to end in a few minutes.
• The user guide explains connections, providers, how to integrate with a host application, storage and security.
• The design documents hold the requirements, the technical design and the roadmap.