burble.dn42 / Services / Internal Services

Internal Services

This page provides some documenation on other services used within burble.dn42 that are not directly available for public use.


Core nodes run an nginx container that acts as a reverse proxy for services hosted in tier2.

The reverse proxy is distributed to improve local response times and is anycast as rproxy.burble.dn42. Most web services provided by burble.dn42 are simply CNAMEs to the reverse proxy which then balances and forwards the request to the actual service.

As well as a reverse proxy, nginx also provides:

  • TLS termination
  • A local page cache to act as a poor man’s CDN
  • Static content server


Envoy Proxy is being introduced as a health checking proxy and load balancer to replace anycasts and nginx for some workloads.


Hashicorp Vault is used to handle secrets across the burble.dn42 network.
Vault is deployed as a 3 node cluster across the Europe core nodes and uses the internal raft database as a back end.

TLS Certificate Authority

Vault acts as the main certificate authority for burble.dn42 PKI.

Vault allows for regular, automated renewal of certificates on short timeframes (typically a rolling week or monthly basis).

SSH Certificate Authority

Vault also acts as an SSH certificate authority, verifying both users and servers within the network.

Server certificates are generated during deployment, whilst user (or role) certificates are short lived and generated on demand.

Deployment Secrets

Vault holds secrets used during node and service deployments.

Most burble.dn42 are built as stateless container images and secrets are pushed from vault in to the live containers at runtime. This ensures the container images do not contain secrets and that secrets can be applied per instance even when using a common image.

Vault also manages database credentials (using the mysql/mariadb integration), and these are also automatically generated and pushed in to container instances on deployment.

The authority to access deployment secrets is inherited, on demand, from the user token during the deployment process. This ensures that even if access was gained to the deployment server, secrets could still not be accessed without also having access to a live user token.


burble.dn42 operates a nats.io cluster as a distributed, network wide, broadcast and RPC solution. The cluster uses Vault managed, ephemeral TLS certs for authentication and encryption.


The burble.dn42 git has an associated CI/CD service based on drone.

The CI/CD service is used to manage DNS, build and publish applications and the burble.dn42 website.