Instead of exposing your service publicly with a domain or TCP proxy, you can use internal links that resolve via private DNS inside your organization and environments. This ensures:
- Secure communication – no public internet exposure.
- Low latency – direct private network traffic.
- Isolation – workloads only talk to what they are allowed to.
Overview
- Every service in DCDeploy can be given an internal hostname.
- Internal DNS works automatically across services inside the same environment.
- Supported for applications, APIs, and databases.
- Works across environments if private networking is enabled.
Use Cases
- Microservices communicating privately (e.g., API ↔ Worker ↔ DB).
- Databases accessible only from backend services, not the internet.
- Multi-environment internal communication (e.g., staging → shared DB).
- Avoiding public endpoints for sensitive workloads.
Internal Link Format
Each service is automatically available at:Example: Connecting to a Database
Suppose you have a PostgreSQL DB and a Node.js backend in the same environment (prod).
-
DB Internal Hostname:
postgres.prod.internal - Backend Connection String:
Example: Private Service-to-Service Communication
Frontend (Next.js) → Backend (Express API) → Database (Postgres)- Frontend connects to backend.prod.internal:3000
- Backend connects to postgres.prod.internal:5432 No public domains are required; traffic stays internal.
Best Practices
- Use internal links by default for all service-to-service communication.
- Only enable public domains / TCP proxies when external access is required.
- Keep secrets (DB URLs, API keys) in DCDeploy secrets instead of hardcoding.
- Test connectivity with:
Troubleshooting
- Can’t resolve internal hostnames? Ensure both workloads are in the same environment or private networking is enabled for cross-env.
- Connection refused? Verify the target service is running and listening on the expected port.
- Need external access temporarily? Use a TCP Proxy or Custom Domain for debugging, then disable when done.
