The Network service provides isolated project networks with subnets and DHCP, routers for internet-bound traffic, floating IPs for stable public access, ports for virtual network interfaces, and security groups for per-port firewall rules.

• PublicEphemeral attaches an instance directly to a public network. Its address can change when the instance restarts.
• PublicStatic connects private project networks to the internet through a router. Floating IPs provide stable inbound addresses.

Use a private network, router, floating IP, and explicit security group rules for public workloads that need stable addressing.

1. Create a network and subnet.
2. Create a router, set PublicStatic as its external gateway, and attach the subnet.
3. Allocate a floating IP and associate it with the public instance.
4. Apply security groups that allow only the required inbound and outbound traffic.
5. Run TLS on the application server or a self-managed reverse proxy.

For global caching or request filtering, place a CDN or WAF in front of the public origin.

A fixed IP belongs to a port on a project network. A floating IP is a public address mapped to that port through one-to-one NAT on the router. Floating IPs persist until you release them and can move between instance ports in the same region.

openstack floating ip create PublicStatic
openstack server add floating ip MY_INSTANCE FLOATING_IP_ADDRESS

The router must use PublicStatic as its external gateway and have an interface on the instance subnet.

Security groups are stateful packet filters attached to ports. Rules allow traffic that matches their protocol, port, and source or destination. Traffic without a matching allow rule is dropped.

Custom groups begin with outbound rules. Add explicit inbound rules for SSH, HTTP, HTTPS, and application ports.

Run a reverse proxy such as HAProxy, Nginx, Caddy, Traefik, or Envoy on a Compute instance. Give the proxy a floating IP, place application instances on a private network, and allow proxy-to-application traffic with security groups.

Configure health checks in the proxy. For an external edge, put a CDN or WAF in front of the proxy's public hostname.

Install the certificate on the application server or reverse proxy that terminates TLS. Certbot can issue and renew Let's Encrypt certificates on Linux instances. Caddy can request and renew certificates as part of its web server configuration.

If a CDN or WAF terminates public TLS, configure TLS from that service to the Quake AI origin as well.

Check the public address, security group, key pair, image username, and boot log in that order. Confirm the instance has a reachable floating IP and an ingress rule for TCP port 22 from your source address.

Verify that the security group allows the application port, the router has PublicStatic as its external gateway, the router has an interface on the instance subnet, and the floating IP points to the expected port.

Start with the instance connectivity runbook. If the runbook does not resolve the issue, open a support ticket with the instance UUID, floating IP, port ID, router ID, and relevant security group rule output.

Choose an application-layer reverse proxy for regional traffic distribution. HAProxy and Nginx provide health checks and backend pools. Caddy and Traefik combine routing with certificate automation. Use an external CDN, WAF, or DNS traffic manager when the source architecture depends on global anycast, edge caching, managed WAF rules, or cross-region failover.

For Kubernetes workloads, a standard Service with type: LoadBalancer requests a public endpoint from the cluster.

A Quake AI network and subnet provide the private address space. A router supplies outbound SNAT and connects the subnet to PublicStatic. Floating IPs provide stable inbound addresses, and security groups filter traffic at each port.