Introduction

OpenShift DeploymentConfig and Kubernetes Deployment both roll out pods, but they are not the same resource or controller model. Deployment is the standard Kubernetes mechanism, while DeploymentConfig is an OpenShift-specific resource with trigger and hook behavior that exists only in OpenShift.

Start With the Kubernetes Deployment

A Kubernetes Deployment is the portable default. It manages ReplicaSets, supports rolling updates, and is understood by the broader Kubernetes ecosystem.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: web
5spec:
6  replicas: 2
7  selector:
8    matchLabels:
9      app: web
10  template:
11    metadata:
12      labels:
13        app: web
14    spec:
15      containers:
16        - name: web
17          image: nginx:1.25

If your goal is maximum portability across clusters, CI pipelines, operators, and documentation, Deployment is usually the better starting point.

What DeploymentConfig Adds in OpenShift

DeploymentConfig is an OpenShift resource from apps.openshift.io/v1. It can react to OpenShift-specific triggers, especially image stream updates and config changes.

1apiVersion: apps.openshift.io/v1
2kind: DeploymentConfig
3metadata:
4  name: web
5spec:
6  replicas: 2
7  selector:
8    app: web
9  template:
10    metadata:
11      labels:
12        app: web
13    spec:
14      containers:
15        - name: web
16          image: image-registry.openshift-image-registry.svc:5000/demo/web:latest
17  triggers:
18    - type: ConfigChange
19    - type: ImageChange
20      imageChangeParams:
21        automatic: true
22        containerNames:
23          - web
24        from:
25          kind: ImageStreamTag
26          name: web:latest

That image-change trigger is one of the main reasons DeploymentConfig exists. When an image stream tag changes, OpenShift can trigger a rollout automatically without external automation.

Compare the Controller Model

The difference is not only YAML syntax. The rollout logic is different too.

Deployment:

• is part of upstream Kubernetes
• manages ReplicaSets
• is the standard object most tooling expects

DeploymentConfig:

• is specific to OpenShift
• supports OpenShift deployment triggers
• supports deployment hooks and OpenShift-specific rollout behavior

So the choice is really about operational behavior and platform dependence, not about two equivalent spellings of the same thing.

How to Choose Between Them

Use Deployment when:

• you want Kubernetes-standard behavior
• you want manifests that stay portable
• you do not need OpenShift image stream triggers

Use DeploymentConfig when:

• you rely on OpenShift image stream integration
• you want OpenShift config-change or image-change triggers
• you need behavior tied specifically to the OpenShift platform

In other words, DeploymentConfig is for OpenShift-specific workflow needs. Deployment is for standard Kubernetes-style application rollout.

Migration Considerations

Teams moving from older OpenShift manifests sometimes migrate from DeploymentConfig to Deployment to reduce platform lock-in. That can be a good simplification, but it is not only a search-and-replace exercise.

You also need to think about:

• how image updates will trigger rollouts afterward
• whether any hooks or deployment policies must be replaced
• whether external automation now needs to do work previously handled by OpenShift triggers

If you remove DeploymentConfig without replacing the behavior you depended on, the manifest may apply successfully while your operational workflow quietly changes.

Common Pitfalls

• Assuming DeploymentConfig is just OpenShift's name for a normal Kubernetes Deployment.
• Choosing DeploymentConfig by default even when no OpenShift-specific trigger behavior is needed.
• Forgetting that image stream triggers are an OpenShift-specific feature, not part of a normal Kubernetes Deployment.
• Migrating to Deployment without replacing the rollout behavior previously driven by triggers or hooks.
• Comparing only manifest syntax instead of comparing controller behavior and platform ownership.

Summary

• Kubernetes Deployment is the standard, portable rollout resource.
• OpenShift DeploymentConfig is an OpenShift-specific resource with trigger and hook behavior.
• Use Deployment for portability and ecosystem alignment.
• Use DeploymentConfig only when you need OpenShift-specific rollout features.
• Treat migration between them as an operational change, not just a YAML rename.