Black Lives Matter

Neon Law

K8s Architecture

K8s Architecture

The above diagram, generated here, details our Kubernetes clusters. We maintain two, one for staging and one for production. Each cluster is deployed on GKE in the Las Vegas region in its own GCP project.

In the diagram above, we highlight the production GKE cluster and the processes deployed from packages built in this repo or vendor-managed software. Let's traverse this diagram starting from the Load Balancer, which is where users interface with Neon Law software.

The Load Balancer is managed by Google Cloud. By enforcing all ingress traffic to funnel through the Load Balancer we can leverage the benefits of this managed service including SSL encryption, WAF, and CDN support.

The Cluster itself is managed using GKE Autopilot. Since we only have stateless deployments, this lessens our DevOps burden.

Kubernetes Ingress

Kubernetes Ingress within our cluster is managed by GKE and GCP. This way we can leverage GCP SSL Certs and IAP for accessing internal company resources. We have three defined ingress rules, @neonlaw/api, Confluent Command Center and superset.


This service points to a Kubernetes deployment we manage that serves our GraphQL API. Please refer to the ./server directory of our GitHub codebase to learn more about what this package does.


We use Google Cloud's managed PostgreSQL offering. We also use Neo4j, Elasticsearch, each can be completely regenerated with data stored in our PostgreSQL database.


We use Google Cloud's managed Pub/Sub offering. Our @neonlaw/workers and web_hooks packages publish to pub sub, and many of our other services subscribe to those messages.

Blob Storage

We use Google Cloud Storage Buckets to store files. All access to this blob storage is stored in a separate GCP Audit account so we have a full accounting of who saw what file. This is important for conflicts.


We use Loglare to collect hooks from pods and post them to BigQuery in our separate Data GCP Project. We also use Logflare as a server for Webhooks for ingesting third-party data.


Some of our applications depend on authentication tokens which we use Auth0 for. After a user authenticates with Auth0, they have a limited-access token to access our service-based deployments.

Non-Service Deployments

Deployments without services listen to changes in one of our Databases, namely Kafka and process data there. These include our worker and email processes.

Neon Law

All content presented herein is for informational purposes only. Nothing should be construed as legal advice. Transmission and receipt of this information is not intended to create and does not constitute, an attorney-client relationship with lawyers on this platform. There is no expectation of attorney-client privilege or confidentiality of anything you may communicate to us in this forum. Do not act upon any information presented without seeking professional counsel.

Pro BonoPGP Key
Join our e-mail list.Sign up for our e-mail list, the Neon Law Monthly.

Copyright © 2021 Neon Law®  under the Apache License v2.

This website is crafted by Nisar.