Standalone dev mint server (no GCP required)

[ggallen]

Problem

Evaluating fullsend requires provisioning GCP infrastructure (Cloud Functions, Secret Manager, WIF) before the platform can be tested. This creates a significant barrier to adoption — teams cannot try fullsend without first committing to a cloud provider.

Solution

Add a standalone development token mint (fullsend mint run) that replaces GCP infrastructure with local equivalents:

• Secret Manager → disk: PEM files stored in a local data directory
• WIF → JWKS: OIDC tokens verified directly via GitHub's JWKS endpoint
• Cloud Functions → HTTP server: Plain HTTP server on localhost, optionally exposed via cloudflared tunnel

Security trade-offs

• OIDC verification is enabled by default; --insecure-no-auth is available for local-only testing and cannot be combined with --tunnel
• Permissive workflow defaults (*) are an accepted risk for short-lived development use; --allowed-workflows provides tighter controls
• PEM files are stored unencrypted on disk, protected by filesystem permissions

Acceptance criteria

• fullsend mint run --data-dir <dir> starts a local mint that serves real GitHub App installation tokens
• fullsend admin install --skip-mint-check --mint-url http://localhost:8321 --mint-data-dir <dir> writes PEMs to disk
• Optional --tunnel flag creates a cloudflared quick tunnel for GitHub Actions access
• OIDC verification works without GCP (direct JWKS validation)
• Documentation covers setup, security model, and limitations

[fullsend-ai-triage]

Triage Summary

Category: Feature — standalone dev mint server to remove GCP dependency for evaluation

Problem: Evaluating fullsend currently requires provisioning GCP infrastructure (Cloud Functions, Secret Manager, WIF) before the platform can be tested, creating a significant adoption barrier.

Approach: Replace each GCP dependency with a local equivalent:

• Secret Manager → disk-based PEM storage
• WIF → direct JWKS OIDC verification
• Cloud Functions → local HTTP server (with optional cloudflared tunnel)

Existing work: PR #1784 directly addresses this issue (Closes #1963) and implements the dev mint server in internal/devmint/. PR #1751 provides the shared internal/mintcore/ library that both the GCP mint and dev mint use.

Security considerations are well-documented: OIDC verification enabled by default, --insecure-no-auth cannot combine with --tunnel, permissive workflow defaults accepted for short-lived dev use.

Proposed Test Cases

1. Start dev mint with --data-dir and verify it serves tokens on localhost
2. Verify OIDC validation via JWKS succeeds without GCP credentials
3. Verify --insecure-no-auth + --tunnel combination is rejected
4. Verify admin install with --mint-data-dir writes PEMs to disk
5. Verify --allowed-workflows restricts token issuance appropriately

This issue is well-specified and has active implementation work in progress.

---

Labels: Dev mint feature directly touches the mint component and install CLI flow, with medium priority as it unblocks evaluation but is not a production defect.

[fullsend-ai-prioritize]

RICE Priority Score: 1.6

Score breakdown

Dimension	Score	Reasoning
Reach	2	This issue affects all prospective users evaluating fullsend, as the current GCP provisioning requirement is a barrier to adoption for any new team. Reducing onboarding friction is platform-wide in scope for new adopters, though it doesn't affect existing production users directly.
Impact	1.5	Requiring GCP infrastructure provisioning before teams can even try the platform is a significant pain point that likely blocks or delays many evaluations. Removing this dependency provides a meaningful efficiency gain for onboarding, though production workflows remain unchanged.
Confidence	0.8	The issue is very well-specified with clear acceptance criteria, documented security trade-offs, and an active PR (#1784) already implementing the feature. The triage summary confirms scope and approach. Minor uncertainty around actual adoption impact.
Effort	1.5	The implementation touches multiple components — a new HTTP server, OIDC/JWKS verification, CLI flag changes, PEM file management, optional cloudflared tunnel integration, and documentation. However, shared infrastructure already exists in internal/mintcore/ (PR #1751), and the PR is in progress, suggesting moderate but manageable complexity.

Formula: (2 x 1.5 x 0.8) / 1.5 = 1.6

[fullsend-ai-triage]

Meeting update — 2026-07-07

Relevant to this issue: The team adopted a public mint service strategy that addresses the core adoption barrier described in this issue — requiring GCP infrastructure provisioning before testing fullsend.

• Decision: the project will transition to a public mint service at mint.send.sh, eliminating the need for manual allow-list management
• This public hosted service reduces the need for each team to deploy their own GCP-backed mint, lowering the adoption barrier this issue targets
• Exploratory work continues on simplifying identity management through the public mint approach

Related PRs: #1413 (public community mint ADR and hosting spike), #1784 (development-only local mint server)

Next steps: Continue developing the public mint service at mint.send.sh

Meeting notes

[ggallen]

This was implemented in PR #2537 (standalone mint with custom role support). The standalone mint at cmd/mint/ provides everything this issue asked for:

• No GCP dependency — PEM keys read from a local directory, OIDC validated directly against GitHub's JWKS endpoint
• Single binary HTTP server — go build -o fullsend-mint ./cmd/mint && ./fullsend-mint
• Tunnel support — documented cloudflared tunnel workflow for GitHub Actions access
• Fallback proxy — can proxy unhandled roles to the hosted mint at mint.fullsend.sh

Full setup guide: docs/guides/infrastructure/standalone-mint.md