Skycloak vs the Community Keycloak Terraform Provider (and How to Use Both)

Last updated: July 2026

There are now two Terraform providers in the Keycloak world, and they do different jobs. The community keycloak/keycloak provider configures a Keycloak you already run: realms, clients, users, and flows, through Keycloak’s admin REST API. The sky-cloak/skycloak provider provisions a managed Keycloak on Skycloak: the cluster itself, plus the platform around it (custom domains, WAF, SIEM, and branding) and the basic building blocks of a realm (realms, users, roles, groups, basic clients, identity providers, SMTP), all through the Skycloak API with a single key. It stops short of deep realm configuration on purpose, which is exactly where the community provider comes in.

Short version: if you host Keycloak yourself, use the community provider. If Skycloak runs Keycloak for you, use the Skycloak provider to provision and secure the instance, then reach for the community provider for anything beyond a basic realm. The two are built to run in the same project. Here is how to decide, with real config.

Two providers, three jobs

The confusion is understandable, because “manage Keycloak with Terraform” can mean three very different things:

1. Provision the instance and its platform. Stand up the cluster, give it a domain, put a WAF in front of it, wire audit logs to your SIEM, and brand the login page. The admin API has no concept of any of this, so the community provider cannot do it. Only the Skycloak provider does this.
2. Bootstrap the realm. Create the realm and its basic building blocks: users, roles, groups, a client with its redirect URIs, an identity provider, SMTP. Both providers cover this level.
3. Configure the realm in depth. Authentication flows, protocol mappers, client scopes, password and token policies, user federation, fine-grained authorization. This is the community provider’s home turf, and it is deliberately out of scope for the Skycloak provider today.

So the Skycloak provider owns job 1 outright and covers job 2, while the community provider owns job 3 and also covers job 2. That shared middle ground is exactly why they combine cleanly: Skycloak provisions and bootstraps, the community provider handles the deep configuration.

What the community Keycloak provider does

The community provider (originally mrparkers/keycloak, now maintained under keycloak/keycloak) is the most popular way to manage Keycloak as code, and for good reason. It has years of coverage across realms, clients, protocol mappers, authentication flows, and user federation. It authenticates against a Keycloak admin API using a service account:

provider "keycloak" {
  client_id = "admin-cli"
  url       = "https://auth.example.com"
  realm     = "master"
}

resource "keycloak_realm" "app" {
  realm   = "app"
  enabled = true
}

resource "keycloak_openid_client" "web" {
  realm_id  = keycloak_realm.app.id
  client_id = "web-app"
  enabled   = true
}

The catch is in the first block: url = "https://auth.example.com". That Keycloak has to already exist, and something other than this provider has to run it, patch it, scale it, and keep it up. The community provider assumes the hard part is already solved.

For the full walkthrough of this workflow, see our guide on using Terraform to set up and configure Keycloak, and for modules, workspaces, and CI, see advanced Terraform patterns for Keycloak.

What the Skycloak provider does

The Skycloak Terraform provider provisions the managed instance and everything around it, then bootstraps the realm, all from one API key:

# Auth reads the SKYCLOAK_API_KEY env var (sk_sc_...)
provider "skycloak" {}

resource "skycloak_cluster" "prod" {
  name     = "production"
  type     = "keycloak"
  size     = "small"
  version  = "26.6.3"
  location = "us"
}

resource "skycloak_realm" "app" {
  cluster_id   = skycloak_cluster.prod.id
  name         = "app"
  display_name = "Application Realm"
  enabled      = true
}

resource "skycloak_cluster_security" "prod" {
  cluster_id = skycloak_cluster.prod.id
  waf = {
    enabled = true
    mode    = "block"
    preset  = "owasp_top_10"
  }
}

There is no url to point at, because the cluster does not exist until Terraform creates it. The same provider also manages custom domains, SIEM destinations, extensions, maintenance windows, and login, email, and theme branding, plus the basic realm entities: realms, users, roles, groups, applications, identity providers, and SMTP. What it does not do is the deep in-realm configuration, authentication flows, protocol mappers, client scopes, password and token policies, so those stay with the community provider (covered in Using both together below).

Side by side

Which one should you use?

• You self-host Keycloak and want to keep it that way. Use the community provider. It is mature, it is free, and it does exactly the job of configuring an instance you operate. Nothing here changes that.
• You are on Skycloak, or evaluating managed Keycloak. Use the Skycloak provider. One terraform apply takes you from an empty file to a running, secured, branded instance, including the parts the admin API cannot reach.
• You are on Skycloak and manage realm configuration as code. Use the Skycloak provider to provision and secure the instance, and add the community provider for the realm configuration beyond the basics. That combination is the next section.

A useful rule of thumb: the community provider is a great fit when the hardest problem you have is realm configuration. The Skycloak provider is the fit when running the instance is also your problem, because it removes that problem instead of scripting around it.

Using both together

A pattern the Keycloak community has recommended for years is to split infrastructure provisioning from realm configuration. With self-hosting, that usually meant two tools and a lot of glue. With Skycloak, that split gets easier, not harder: the Skycloak provider handles provisioning and the basic realm bootstrap, and the community provider handles the deep realm configuration, both pointed at the same cluster. It is the same infrastructure-versus-application separation the community has always recommended, minus the servers.

The handoff is straightforward. The Skycloak provider creates the cluster and exposes its URL; the community provider consumes that URL and layers on top:

# 1. Skycloak provisions the managed cluster + platform
provider "skycloak" {}

resource "skycloak_cluster" "prod" {
  name     = "production"
  type     = "keycloak"
  size     = "small"
  version  = "26.6.3"
  location = "us"
}

resource "skycloak_realm" "app" {
  cluster_id = skycloak_cluster.prod.id
  name       = "app"
  enabled    = true
}

# 2. The community provider layers deep in-realm config on the same cluster
provider "keycloak" {
  client_id = var.kc_admin_client_id
  url       = skycloak_cluster.prod.url
  realm     = "master"
}

resource "keycloak_authentication_flow" "step_up" {
  realm_id = skycloak_realm.app.name
  alias    = "step-up-mfa"
}

The key line is url = skycloak_cluster.prod.url: the community provider points at the cluster the Skycloak provider just created, so Terraform orders the operations correctly. Keep the two concerns in separate modules (and ideally separate state) so provisioning changes and config changes have independent blast radius, exactly as you would with any infrastructure-versus-application split.

How much you lean on the community provider depends on how much realm configuration you keep as code. If a basic realm is all you provision, the Skycloak provider alone is simpler. The moment you need authentication flows, protocol mappers, client scopes, or fine-grained policies, layer the community provider on top.

Migrating from a community-only setup

If you already manage a self-hosted Keycloak with the community provider and you move to Skycloak, you do not throw your config away. Provision the managed cluster with the Skycloak provider, migrate your realms and users, then repoint the community provider’s url at the new cluster to keep managing your deep realm configuration. Your existing HCL for clients and flows keeps working, because it is the same Keycloak underneath.

FAQ

Is Skycloak a Terraform provider?
Yes. sky-cloak/skycloak is published on the Terraform Registry. It manages your managed Keycloak environment (clusters, realms, identity providers, security, and branding) as code. This is separate from the community keycloak/keycloak provider, which configures a Keycloak you run yourself.

Do I need both providers?
It depends on how deep your realm configuration goes. The Skycloak provider alone covers provisioning, the platform, and basic realm setup: realms, users, roles, groups, basic clients, identity providers, and SMTP. For deep realm configuration as code, authentication flows, protocol mappers, client scopes, password and token policies, pair it with the community provider pointed at the same cluster.

Can the Skycloak provider configure realms, users, and clients?
It can create them at a basic level: realms (name and core toggles), users, roles, groups, basic clients (redirect URIs, grant types, PKCE), identity providers, and SMTP, alongside the platform resources. It does not cover deep realm configuration such as authentication flows, protocol mappers, client scopes, or password policies. Manage those with the community provider.

How does each provider authenticate?
The Skycloak provider uses a Skycloak API key (sk_sc_...), typically via the SKYCLOAK_API_KEY environment variable. The community provider uses an admin service account on the Keycloak instance itself.

Does the Skycloak provider work with the public REST API?
Yes, they are the same surface. Anything the provider does maps to the Skycloak REST API, so you can mix Terraform with direct API calls or your CI/CD pipeline.

Ready to manage your Keycloak as code? See the Skycloak Terraform provider for the full resource list and a one-file example, or start a free trial to mint your first API key.