[Design Discussion] Deployment Profiles

[senthalan]

Related Feature Issue

#1114

Problem Summary

Platform operators deploying Thunder for specific use cases (government compliance, service-to-service auth, token validation) must deploy the full Thunder distribution with all endpoints exposed. This increases attack surface, binary size, and resource consumption - making Thunder unsuitable for compliance-focused or resource-constrained deployments.

This design proposes Deployment Profiles - separate Thunder binaries (for example thunder-sts, thunder-gov) that include only required capabilities.

High-Level Approach

Code Structure

• Create separate entry points under backend/cmd/<profile>/ for each profile
• Add profile-specific initialization files (e.g., init_sts.go) in internal packages to customize capabilities per profile
• Reuse existing internal packages - no business logic duplication
• Extract common server code from backend/cmd/server to a shared location

Build & Deployment

• Add new Makefile targets (build_sts, build_gov) for building profile binaries
• Create dedicated Dockerfiles and Helm charts per profile
• Profile-specific deployment.yaml with minimal database dependencies

Testing

• Separate integration and e2e tests for each profile
• Extract reusable test utilities to a common location

Architecture Overview

Directory Structure

backend/
├── cmd/
│   ├── server/           # Full Thunder (existing)
│   ├── sts/              # STS Profile
│   │   ├── main.go
│   │   ├── servicemanager.go
│   │   └── repository/conf/deployment.yaml
│   └── gov/              # Government Profile
│       ├── main.go
│       ├── servicemanager.go
│       └── repository/conf/deployment.yaml
│
└── internal/
    └── oauth/oauth2/
        ├── granthandlers/
        │   ├── init.go       # Full profile
        │   └── init_sts.go   # STS profile
        ├── discovery/
        │   ├── init.go       # Full profile
        │   └── init_sts.go   # STS profile
        └── introspect/
            ├── init.go       # Full profile
            └── init_gov.go   # Government profile

Profile Capabilities

Capability	Full	STS	Gov
Token Endpoint	✅	✅	❌
Introspection	✅	✅	✅
JWKS	✅	✅	✅
Discovery	✅	✅	✅
Authorization	✅	❌	❌
UserInfo	✅	❌	❌
User Management	✅	❌	❌
Flow Execution	✅	❌	❌
Branding	✅	❌	❌

Database Dependencies

Database	Full	STS	Gov
Thunder DB	✅	✅	✅
Runtime DB	✅	❌	❌
User DB	✅	❌	❌

Security Considerations

• Reduced Attack Surface: Profiles expose only required endpoints, minimizing vulnerability exposure
• Compliance Ready: Government profile designed for security audits - every endpoint is justifiable

Impacted Areas

• Build System: New Makefile targets, build.sh functions
• Docker: New Dockerfiles per profile
• Helm Charts: New charts or profile-specific values
• CI/CD: Pipeline updates for building/testing all profiles
• Documentation: Profile-specific deployment guides
• OAuth Module: New init_*.go files for profile-specific initialization

Alternatives Considered

Alternative 1: Configuration-based feature flags

• Pros: Single binary, runtime flexibility
• Cons: Binary size unchanged, all code still present
• Decision: Rejected - doesn't achieve smaller binaries or true capability isolation

Alternative 2: Go build tags

• Pros: Compile-time flexibility, single codebase
• Cons: Combinatorial explosion of build/test matrix, implicit dependencies can cause missing symbol errors at link time
• Decision: Rejected - complexity outweighs benefits

Alternative 3: Plugin architecture

• Pros: Maximum flexibility, hot-loadable features
• Cons: Go plugin limitations (Linux-only, same Go version required), performance overhead
• Decision: Not suitable for current needs

Chosen Approach: Separate binaries with explicit init files

• Pros: Explicit code paths, easy to test each profile independently, smaller binaries
• Cons: Multiple binaries to maintain, some init code duplication
• Decision: Best balance of simplicity, testability, and capability isolation

Questions for Community Input

No response

[rajithacharith]

+1 with the chosen approach.

My suggestion is to modularize the services and expose them as public packages. The Thunder repository itself can then provide distributions such as thunder and thunder-sts, differentiated via separate main.go entry points.

This approach also enables open-source developers to build their own identity solutions by composing only the features they need using the exposed packages.

I’m not aligned with having a thunder-gov distribution within the Thunder repository itself; that would be better maintained as a separate repository.

I was referring to the backend. When implementing we might need a way that the console would be able to figure out what are the available features from the runtime

[ThumulaPerera]

If I understand correctly, we are trying to achieve 2 objectives.

1. Reduced attacked surface => for compliance-focused deployments
2. Smaller binary size and reduced resource consumption => for resource-constrained deployments

Chosen approach achieves both, but practically I think the number of Deployment Profiles we can maintain with that approach will be limited.

Also, for a majority of Thunder deployments, in my opinion 2 will not be of high importance given the current binary size and resource consumption. But more would benefit from 1. I suspect the number of feature combinations required for different such deployments might be more than we can practically provide with the selected approach. For such cases, alternative 1 could be a reasonable solution.

My suggestion is to treat alternative 1 as complementary to the chosen approach rather than treating it as an alternative.

I'm +1 to start with the chosen approach. As Thunder gets adopted we can gauge whether the statement number of feature combinations required for different such deployments might be more than we can practically provide with the selected approach is true or not. Based on that, we can revisit whether we need to implement alternative 1 as well

[ThumulaPerera]

Also, have we thought about whether we maintain profile specific sql schemas and API specs (maybe this is less important) as well?