Networking

Overview

Every service in Ardor gets network connectivity out of the box. Services can talk to each other over the internal network, and you can expose them publicly when needed.

Cerebrum configures networking. Ask “connect my API to the database” or “make this service public” — Cerebrum will set up the connections and environment variables. The details below explain how it works.

Internal Network

Services communicate privately using internal URLs. Fast, secure, no internet roundtrip.

Public Access

Expose services to the internet with a public URL for APIs, websites, and webhooks.

How Services Connect

Each service gets two URLs:

URL Type	Format	Use For
Internal	`service-<uuid>:<port>`	Service-to-service communication
Public	`https://<port>-<uuid>.ardor.cloud`	Browser access, external clients

For example:

Internal: service-11bc044b-cb51-4fe2-b2d3-06e8e04656a0:8080
Public: https://8080-11bc044b-cb51-4fe2-b2d3-06e8e04656a0.ardor.cloud

Internal communication is faster and more secure — traffic never leaves Ardor’s network. Use internal URLs whenever services talk to each other.

Internal Network

Services can reach any other service on Ardor’s internal network — if they know the internal URL. Think of the internal URL as a private address: without it, services can’t find each other.

You can share internal services between solutions if needed — just share the internal URL. For extra security, add authentication to your service.

Finding Internal URLs

Each service displays its internal URL in the service settings. The format includes a unique identifier:

service-<uuid>:<port>

For example:

service-11bc044b-cb51-4fe2-b2d3-06e8e04656a0:5432
service-a3f2e891-1234-5678-abcd-ef0123456789:6379

The UUID makes internal URLs hard to guess — but don’t rely on this alone. Add authentication to services that handle sensitive data.

Connecting Services

To connect from one service to another, use the internal URL. Store it in an environment variable for flexibility:

Database Connection
Redis Connection
API Call

import os

# Internal URL from environment variable
db_host = os.environ['DATABASE_HOST']  # e.g., service-11bc044b-...:5432

DATABASE_URL = f"postgresql://user:password@{db_host}/myapp"

import os
import redis

redis_host = os.environ['REDIS_HOST']  # e.g., service-a3f2e891-...:6379

r = redis.Redis.from_url(f"redis://{redis_host}")

import os
import requests

api_url = os.environ['API_INTERNAL_URL']  # e.g., service-xyz...:8080

response = requests.get(f'http://{api_url}/health')

Always store internal URLs in environment variables — never hardcode them. This makes it easy to change connections without modifying code.

Cross-Service Communication

Backend services can reach any other service by its internal URL:

Browser can’t use internal URLs. If your frontend runs in the browser (React, Vue, etc.), it’s outside Ardor’s network. Set up a reverse proxy in your frontend service to route API requests internally — this is the recommended pattern.

Public vs Private Services

When configuring a service, you choose its visibility:

Public
Private

When to use:

Web applications users visit
APIs external clients call
Webhook endpoints

What happens:

Service gets a public URL: https://<port>-<uuid>.ardor.cloud
Anyone on the internet can access it
Still accessible internally too

When to use:

Databases (PostgreSQL, MongoDB, Redis)
Internal microservices
Background workers
Anything that shouldn’t be exposed

What happens:

No public URL
Only reachable via internal URL: service-<uuid>:<port>
More secure — no attack surface from internet

Never expose databases publicly. Always keep them private and connect from your backend services using internal URLs.

Port Configuration

Each service listens on a specific port. Ardor passes this as the PORT environment variable.

How Ports Work

You configure the port in service settings (default: 8080)
Ardor injects it as PORT environment variable
Your app reads PORT and listens on it
Both internal and public URLs route to this port

Reading the Port

Python
Node.js
Go

import os
port = int(os.environ.get('PORT', 8080))
app.run(host='0.0.0.0', port=port)

const port = process.env.PORT || 8080;
app.listen(port, '0.0.0.0');

port := os.Getenv("PORT")
if port == "" {
    port = "8080"
}
http.ListenAndServe("0.0.0.0:"+port, nil)

Always bind to 0.0.0.0, not localhost or 127.0.0.1. Otherwise your service won’t be reachable from outside the container.

Port in Internal URL

The port is included in the internal URL you get from service settings:

service-<uuid>:<port>

Use it directly — no need to specify the port separately.

Environments

Environments belong to a solution — create as many as you need. Each environment is completely independent with its own services, URLs, and configuration.

Environments Guide

Learn how to create and manage environments for dev, staging, production, and feature branches.

Common Patterns

API + Database

Setup:

PostgreSQL service — Private
API service — Public, connects via internal URL stored in env var

Frontend + Backend + Database (Recommended)

Setup:

PostgreSQL — Private
Redis — Private
API Backend — Private, only reachable via internal URL
Frontend — Public with reverse proxy, routes /api/* to backend internally

Best practice: Keep your API backend private and route requests through your frontend’s reverse proxy. This way only one service is exposed to the internet.

Frontend + Public API (when needed)

If you intentionally need a public API (for external clients, mobile apps, webhooks): Use this when:

External apps need to call your API directly
You’re building a public API for third parties
Mobile apps need direct backend access

Microservices

Setup:

Only the API Gateway is public
All microservices are private, communicate via internal URLs

Troubleshooting

Can't connect to another service

Check:

Is the target service running? Check its status and logs
Are you using the correct internal URL and port?
Are both services in the same environment?

Ask Cerebrum to help diagnose connection issues.

Connection refused errors

Cause: Target service isn’t listening on the expected port.Check:

Is the service reading the PORT environment variable?
Is it binding to 0.0.0.0?
Check the service logs for startup errors

Public URL not working

Check:

Is the service set to Public visibility?
Is the service running and healthy?
Is it listening on the configured port?

Timeout connecting to database

Check:

Is the database service running?
Are you using the internal URL (not trying to connect externally)?
Check database logs for connection limit issues

Best Practices

Keep databases private

Never expose databases to the internet. Always use private visibility and connect via internal URLs.

Keep API backends private when possible

Unless you need a public API for external clients, keep your backend private and route requests through your frontend’s reverse proxy. One public endpoint = smaller attack surface.

Use environment variables for URLs

Don’t hardcode internal URLs. Store them in variables so you can change them without code changes.

DATABASE_HOST = os.environ['DATABASE_HOST']

Minimize public services

Only expose what needs to be public. Fewer public endpoints = smaller attack surface.

Add authentication to sensitive services

Internal URLs with UUIDs are hard to guess, but add authentication for extra security on services that handle sensitive data.

What’s Next

Variables & Secrets

Store connection strings and credentials securely

Docker Images

Deploy databases and caches from Docker Hub

Deployments

Deploy your connected services to production

Logging

Debug connection issues with logs

Introduction

Cerebrum

Console

Services

Account

Pricing

Overview

Internal Network

Public Access

How Services Connect

Internal Network

Finding Internal URLs

Connecting Services

Cross-Service Communication

Public vs Private Services

Port Configuration

How Ports Work

Reading the Port

Port in Internal URL

Environments

Environments Guide

Common Patterns

API + Database

Frontend + Backend + Database (Recommended)

Frontend + Public API (when needed)

Microservices

Troubleshooting

Best Practices

What’s Next

Variables & Secrets

Docker Images

Deployments

Logging

Introduction

Cerebrum

Console

Services

Account

Pricing

​Overview

Internal Network

Public Access

​How Services Connect

​Internal Network

​Finding Internal URLs

​Connecting Services

​Cross-Service Communication

​Public vs Private Services

​Port Configuration

​How Ports Work

​Reading the Port

​Port in Internal URL

​Environments

Environments Guide

​Common Patterns

​API + Database

​Frontend + Backend + Database (Recommended)

​Frontend + Public API (when needed)

​Microservices

​Troubleshooting

​Best Practices

​What’s Next

Variables & Secrets

Docker Images

Deployments

Logging

Overview

How Services Connect

Internal Network

Finding Internal URLs

Connecting Services

Cross-Service Communication

Public vs Private Services

Port Configuration

How Ports Work

Reading the Port

Port in Internal URL

Environments

Common Patterns

API + Database

Frontend + Backend + Database (Recommended)

Frontend + Public API (when needed)

Microservices

Troubleshooting

Best Practices

What’s Next