Self-Built Identity Host vs. Containerized Identity Server
Self-hosting an identity server offers two deployment paths: running a pre-packaged containerized server image or building a custom identity host application using a framework SDK. Both options can be deployed as containers, but they differ in software packaging, configuration management, and developer control.
Pre-packaged containerized servers like Keycloak bundle the protocol engine, administration UI, user store, and login templates inside a vendor-maintained image. You deploy the container and configure settings via admin APIs or web consoles. Framework SDKs like Duende IdentityServer let you build an identity host directly inside an ASP.NET Core solution, giving you source-level control over configuration and deployment artifacts.
This guide was last reviewed on September 9, 2026. Both approaches evolve quickly. Verify current details against the linked documentation and vendor sources.
Architecture: Pre-Packaged Servers vs. Framework SDKs
Evaluating these options requires looking at the components packaged inside the container runtime.
A ready-made server image is batteries-included: it bundles the protocol engine, an admin console, themes, a built-in login UI, and user federation, all pre-assembled by the vendor. You stand it up without writing code, then configure it from the outside through a console, files, or an API.
A self-built identity host compiles the identity framework SDK into an ASP.NET Core host application. IdentityServer manages OAuth, OpenID Connect, and SAML protocol logic, while you integrate components: user interface views, database persistence, and user identity management. This produces a custom container image or deployment package running in your preferred hosting environment.
Pros and Cons of Pre-Packaged Identity Servers
Pre-packaged container images provide immediate access to authentication workflows, administration dashboards, user management interfaces, and directory federation out of the box. You deploy the image, configure settings via console or REST API, and scale by running additional instance replicas.
Running pre-packaged servers introduces additional software stacks and deployment models into your environment. Server configurations, realm exports, and administrative settings must often be managed separately from primary application code repositories.
Pros and Cons of Self-Built Identity Hosts
Building an identity host with a framework SDK integrates identity management into your primary software stack. Clients, scopes, and claims are defined directly in C# code, login interfaces are constructed with standard web templates (like Duende UI templates), and deployment follows your standard CI/CD release pipeline.
Creating a custom host requires initial software setup and UI development rather than pulling an off-the-shelf image. In return, all identity settings reside in source-controlled code, built and deployed using your existing .NET knowledge, tools and CI/CD pipelines.
Containerized Server vs. Self-Built Host Comparison
| Aspect | Ready-made containerized server (e.g. Keycloak) | Self-built identity host (e.g. Duende IdentityServer) |
|---|---|---|
| What ships in the image | Full server, admin console, login UI, federation | Your ASP.NET Core application host composed from the SDK |
| Time to first login | Fast; pull and configure | Slower; compose and build the host |
| Configuration model | Admin console, files, REST API | Code and/or configuration stores |
| Login UI | Built-in, theme-based | You build it (templates available) |
| Customization ceiling | The server's extension model | Full control; it is your code |
| Runtime / stack | A separate server application and database | ASP.NET Core host application and separate database |
| Where config lives | Server console and API (exportable, but managed separately) | In your codebase, versioned with everything else |
| Operational surface | Operating a distinct software product and stack | Operating an ASP.NET Core service using your standard .NET tooling and pipeline |
| Compliance and governance | You control the deployment boundary; governance follows vendor releases | You control the full boundary and code integration within your standard compliance routines |
| Cost model | Typically open-source or vendor support licensing; plus infrastructure costs | Commercial framework license (tiered/flat) plus infrastructure |
Neither column is universally right. A ready-made server is the shortest path to a running login; a self-built host is the better fit when identity should be part of your own system rather than a separate stack beside it.
Key Differences in Identity Server Operations
The choice depends on whether you prefer managing identity as a pre-packaged third-party server product or as a .NET service host built with a framework SDK.
Pre-packaged server images provide instant setup and administration tools, operating as standalone services managed separately from primary application code bases. This fits teams seeking ready-to-use admin consoles without writing custom host code.
Self-built identity hosts, like Duende IdentityServer, are also typically deployed as dedicated, standalone services backed by a database. The key advantage is that the host is written in C# and runs on ASP.NET Core, allowing it to leverage your existing .NET libraries, developer skillsets, and CI/CD workflows.
When to Use a Pre-Packaged Containerized Server
- You want a working identity server as fast as possible, with an admin console and a login UI you do not have to build.
- You are comfortable operating a separate server application and database alongside your primary applications.
- Your customization needs are met by the server's themes and extension points.
- Your team does not have a strong platform preference or requirement for unified application codebases.
When to Build an Identity Host
- You want identity to be part of your main solution codebase, configured in code and shipped by your primary CI/CD pipeline.
- You want full control over the login experience and claim logic rather than a themed built-in UI.
- You prefer deploying a dedicated identity host using standard .NET technology and your primary CI/CD tooling.
- You want your identity configuration versioned and tested alongside the rest of your application.
How to Configure Identity Servers in Containers
Both deployment options require configuring persistent data and key management to run reliably inside container environments:
- Data Protection key ring: container filesystems are ephemeral, so point Data Protection at a shared, persistent store (a database, a mounted volume, or a cloud key service) rather than local disk, or each instance will generate its own keys.
- Signing key store: the token signing keys must be reachable by the whole cluster and survive restarts, so use a shared store rather than one scoped to a single container.
- Stateless scaling: IdentityServer does not require server affinity, which is what lets orchestrators route requests to any replica. If you enable server-side sessions, back them with a shared store.
- Forwarded headers: behind an ingress or proxy, handle forwarded headers so the host sees the real request scheme and host. The deployment documentation notes this is often the right choice for cloud-hosted and Kubernetes environments.
Where This Connects
- For a deeper, product-level look at the best-known ready-made server, see Keycloak vs. Duende IdentityServer.
- If the real question is whether to run identity yourself at all, see self-host vs. SaaS identity.
- If you are weighing a framework against writing the server yourself, see build your own authentication or use an identity server.