Skip to main content

Networking

Molnett provides flexible networking options to expose your services to the internet and enable communication between services within your project.

Public Access & Ports​

When you define a service, you can specify ports for your containers. By setting publish: true for a port in your molnett.yaml, Molnett will make that port accessible externally.

# In your molnett.yaml
name: my-web-app
containers:
  - name: web
    image: my-web-image:latest
    ports:
      - target: 8080  # Your app listens on this port inside the container
        publish: true # This port will be made public
  • Molnett URLs: For each published port, Molnett automatically generates a unique, secure URL (e.g., https://your-service-name-RANDOM_STRING.molnett.dev). You can find this URL in the service details in the Molnett Web UI or via molnctl get service your-service-name.
  • HTTPS by Default: All publicly accessible Molnett URLs are secured with HTTPS, with SSL/TLS certificates managed by Molnett.

Custom Domains​

While Molnett provides default URLs, you can also use your own custom domains for your services.

(Details on how to configure custom domains will be added here. This typically involves:)

  • Adding the domain to your Molnett project/service via the UI or molnctl.
  • Configuring DNS records (e.g., CNAME or A records) with your domain registrar to point to Molnett.
  • SSL/TLS certificate management for custom domains (Molnett may offer automated Let's Encrypt or allow uploading custom certs).

Using molnctl (Example commands - to be confirmed):

# Add a custom domain to a service
molnctl create domain --service my-web-app --hostname www.example.com

# List custom domains
molnctl get domains --service my-web-app

Internal Networking (Service-to-Service Communication)​

Services deployed within the same Molnett project and environment can typically communicate with each other using internal DNS names, even if their ports are not publicly published.

  • Service Discovery: Molnett usually provides an internal DNS name for each service, often in the format <service-name>.<environment-name>.<project-name>.svc.cluster.local (the exact format needs to be documented based on Molnett's implementation).
  • Example: If you have a backend-api service and a frontend-app service in the same project/environment, your frontend-app could reach the backend-api on its internal port (e.g., http://backend-api:8000).

Using host_aliases for specific needs: If you need more control over DNS resolution within a service (e.g., for legacy applications or complex setups), you can use the host_aliases feature in your molnett.yaml:

# In your molnett.yaml
name: my-app
host_aliases:
  - ip: "10.0.0.50" # An internal IP or an IP of another service/resource
    hostnames:
      - "legacy-service.internal"
containers:
  # ... your container definitions

This will add an entry to /etc/hosts inside your service's containers.

Security​

  • Network Policies (Future): (Mention if network policies for fine-grained control over ingress/egress traffic between services are planned).
  • Published Ports: Only ports explicitly marked with publish: true are exposed externally. All other ports are only accessible within the internal Molnett network for your project.

(Further details on load balancing, IP ranges, and any advanced networking features will be added as they become available or are documented.)