diff --git a/docs/src/main/asciidoc/deploying-to-openshift.adoc b/docs/src/main/asciidoc/deploying-to-openshift.adoc
index 7053ae978ecaa..1cf85aa81df3f 100644
--- a/docs/src/main/asciidoc/deploying-to-openshift.adoc
+++ b/docs/src/main/asciidoc/deploying-to-openshift.adoc
@@ -89,6 +89,9 @@ include::{includes}/devtools/build.adoc[]
 
 TIP: If you want to test your application immediately then set the `quarkus.openshift.route.expose` config property to `true` to <<exposing_routes,expose the service automatically>>, e.g. add `-Dquarkus.openshift.route.expose=true` to the command above.
 
+[#re-deploy-with-service-binding]
+NOTE: When using `DeploymentConfig` and https://quarkus.io/guides/deploying-to-kubernetes#service_binding[Service Binding], re-deploying might remove the configuration added by OpenShift to allow service discovery. A new container image build will trigger a refresh of the Quarkus app in OpenShift: `-Dquarkus.container-image.build=true` which might be enough in most situations. If you need to update the OpenShift resources, you need to delete the binding first to create it again after new deployment.
+
 This command will build your application locally, then trigger a container image build and finally apply the generated OpenShift resources automatically.
 The generated resources use OpenShift's `DeploymentConfig` that is configured to automatically trigger a redeployment when a change in the `ImageStream` is noticed.
 In other words, any container image build after the initial deployment will automatically trigger redeployment, without the need to delete, update or re-apply the generated resources.