DB-driven platform config in forge-social

Connecting forge-social to Mastodon, LinkedIn, or X requires OAuth app credentials from the platform's developer portal. Before v0.5.0, those credentials lived in environment variables: MASTODON_CLIENT_ID, MASTODON_CLIENT_SECRET, MASTODON_INSTANCE_URL, and so on.

That works when a developer controls the server. It breaks down when an operator does not have shell access.

Platform config as a content record

v0.5.0 introduces PlatformConfig — a database record that holds OAuth app credentials for a given platform, encrypted at rest. Setting up a platform is an MCP call:

create_platform_config
  platform: "x"
  client_id: "<from developer.x.com>"
  client_secret: "<from developer.x.com>"

For Mastodon, which also needs an instance URL:

create_platform_config
  platform: "mastodon"
  client_id: "<id>"
  client_secret: "<secret>"
  instance_url: "https://mastodon.social"

The credentials are encrypted with AES-256-GCM using Config.Secret — the same key used for OAuth tokens and webhook secrets throughout forge-social. One root secret, consistent across the stack.

create_platform_config requires Admin role. The stored values cannot be read back through the API — only overwritten.

From the CLI

forge-cli social platform configure \
  --platform x \
  --client-id <id> \
  --client-secret <secret>

forge-cli social platform configure \
  --platform mastodon \
  --client-id <id> \
  --client-secret <secret> \
  --instance-url https://mastodon.social

Same operation, same role requirement.

What changes for existing installations

Environment variables for platform credentials are no longer read. Existing forgesocial.Config fields for MastodonConfig.ClientID and similar are replaced by a database lookup at OAuth time.

If you are upgrading from v0.4.x, run create_platform_config (or forge-cli social platform configure) for each platform before attempting to connect new credentials. Existing connected accounts — access tokens already stored in PlatformCredential — continue to work without re-authorisation.

Why this matters

The env-var model couples platform setup to server deployment. Adding a new platform, rotating credentials, or reconfiguring an instance URL requires a server restart. Operators who do not have shell access cannot do it at all.

With DB-driven config, platform setup is an operator action. No deployment, no server access, no restart. An agent with Admin role can configure a platform and hand off to a human to complete the OAuth flow.

forge-social v0.5.0, forge-cli v0.8.0.

*See forge-social for full installation and wiring reference.* *See X support for connecting an X account.*