Skip to main content
DCDeploy provides a built-in private network for all workloads.
This allows services to securely communicate with each other inside the same namespace or environment without exposing them to the public internet.

​
Overview

  • Every environment (env) in DCDeploy has its own isolated private network.
  • Services inside the same environment can reach each other using internal DNS names.
  • Traffic inside the private network:
    • Never leaves DCDeploy’s infrastructure.
    • Is protected with encryption-in-transit.
    • Avoids public exposure unless explicitly configured.

​
Namespaces & Isolation

  • Each namespace (per environment) acts as a separate private network.
  • Services in different namespaces cannot talk to each other unless connected via a private link.
  • Example:
    • service-a in staging cannot reach service-b in production unless explicitly linked.

​
Example: Internal Communication

You can call one service from another using its service name + namespace. 
curl http://my-api.staging.svc.cluster.local:3000/health
  • my-api → service name
  • staging → namespace (environment)
  • .svc.cluster.local → private network domain suffix

​
Use Cases

  • Connect a backend API to a database without public exposure.
  • Secure microservice-to-microservice communication inside the same environment.
  • Run internal-only workloads (admin panels, monitoring agents).

​
Public vs Private

Network TypeAccessible FromUse Case
PublicInternetExposing APIs, websites, external clients
PrivateInternal onlyDatabases, internal APIs, secure services

​
Best Practices

  • Use private network for all databases and sensitive services.
  • Only expose public endpoints when necessary.
  • Combine with TCP Proxy for secure DB access if needed externally.
  • Use private services + internal links to connect across environments.