Architecture
How EdgeLex actually runs.
This page is for the person who signs off on systems — the IT admin, the legal-tech adviser, the partner who has to defend the decision. Deployment topologies, the services inside, what talks to the outside, identity, audit, and the exit path. Everything here is the shipped architecture — not a roadmap.
$ edgelex deploy --self-hosted
✓ 14 services healthy · postgres · vector store · document engine
✓ models: local llama-70b + frontier via your keys — governed per matter
# your metal, your data, your models. our OS.
Deployment topologies
Three ways to run it. One platform.
The same code, the same governance, the same audit trail in every topology — deployment is a choice, not a different product.
EdgeLex Cloud
managedWe run the full stack for your firm in an isolated tenancy. Your firm's realm, your data, your audit trail — operations, upgrades, and backups handled for you.
- Per-firm security realm and encryption
- No cross-tenant data paths
- Same governance model as self-hosted
What you need: nothing but browsers.
Private cloud
your accountThe same stack deployed into your own cloud account. You own the infrastructure bill, the network boundary, and the keys; EdgeLex ships the images and the runbooks.
- Your VPC, your IAM, your KMS
- Egress under your network policy
- Managed upgrades on your schedule
What you need: a cloud account and a VPC.
On-premises
your metalThe complete platform on servers you rack. Everything — database, vector store, document engine, models — inside your walls. Air-gap-tolerant by design.
- No required external dependencies
- Local model serving on your GPUs
- Your backup and DR regime
What you need: one or two servers; a GPU if you want local models and transcription.
What’s actually inside
The services your firm would otherwise rent — running as one deployment.
This is why the SaaS-versus-self-host question changes with EdgeLex: it isn’t one app you’d host, it’s the stack you’d otherwise buy as six subscriptions.
Identity
OpenID Connect with a dedicated identity realm per firm. Your users, your MFA policy, your session rules — no shared login plane.
System of record
One PostgreSQL database owns every matter, document, task, and ledger entry. Every query is scoped to your firm's realm at the data layer.
Search & retrieval
Full-text and vector search over your own corpus, inside the deployment. Nothing is indexed anywhere else.
Document engine
Native DOCX and PDF editing and rendering in the deployment — documents are edited where they're stored, not round-tripped through a third party.
Mail server
A complete mail platform — SMTP, IMAP, spam filtering, DKIM/SPF/DMARC — running as part of the deployment. The firm's mail never transits an advertising company.
Media & transcription
WebRTC meeting rooms with recording on controlled storage, and speech-to-text served on the deployment's own GPU. Testimony doesn't leave to get transcribed.
Model serving
Local open-source models on your hardware, frontier models under your own API keys — both behind the same governance plane.
Log store
A dedicated logging database for activity, security events, and every AI decision — the same store that drives the live security dashboards and compliance reports.
What talks to the outside
The complete egress list. It’s short.
The first question a network admin asks, answered in one table — and every row marked optional can be turned off.
The stack
Five layers, one permission model.
Every application shares one data plane, one identity plane, and one audit plane — which is what makes the governance real instead of aspirational.
Application
Matters, documents, email, calendar, billing, meetings, tasks, intake, data rooms — one permission model
AI runtime
Lex agents, delegations, and graph execution under per-turn tool binding and task classification
Governance
Model policy per firm and per matter · approval gates · typed evidence verification · spend accounting
Data
PostgreSQL system of record · vector search · document store — every record realm-scoped to your firm
Audit
Structured event log across every surface and every AI action — queryable, exportable, yours
Audit, live
The monitoring plane is part of the product.
Activity logging with per-event risk scoring, security-event detection, anomaly recommendations, and scheduled compliance reports — the screens below are live on the Security page.
User Logging SystemSystem healthyLive Updates100Recent Activities0Security Events1,306Active Alerts
System Health● healthy
Total Activities · last 24h
Active Users · unique
High Risk · score ≥ 70
Security Events · failed attempts
document access43940.9%
matter access27125.2%
admin access23622.0%
document version363.4%
client access333.1%
Failed Attempts
4xx/5xx errors
After Hours
Outside 6am–10pm
Avg Risk Score
Out of 100
Access Locations
Unique IPs
Model governance
The AI plane is policy-first.
Which models exist, where they may run, and what they cost — decided by the firm in the database, enforced before any call.
Frontier models
Run under your own API keys. Selectable and disableable per firm; usage metered and billed to matters.
Local models
Open-source models served on your own hardware. No tokens leave the deployment.
Your firm's model
Fine-tune on your own curated work product, inside your infrastructure. Weights never leave.
Policy
Default-deny: a model is available only where governance says so. The task is classified before any model runs.
AI Model Governance
Control which AI models the Lex Runtime can use, set defaults, and monitor usage.
🛡 Runtime Governance Active authority
The Lex Runtime checks firm policy in the database before any model call. Browser clients cannot override this policy.
The questions you’ll actually ask
Ten answers for the evaluation memo.
Where does our data live?
In one PostgreSQL system of record plus file storage you choose — EdgeLex Cloud tenancy, your cloud account, or your own servers. There is no second copy in someone else's analytics pipeline.
Who holds the keys?
You can. Private-cloud and on-prem deployments use your KMS or your disks; provider API credentials are stored AES-256-GCM encrypted, and firms can bring their own keys.
Is our data used to train models?
No. Client data is never used to train anyone else's models. Your own fine-tuned firm model is built only from work product your lawyers deliberately curate — and its weights never leave your deployment.
What leaves the network?
See the egress table above — frontier model calls (only if allowed, under your keys), live citation checks, court fetches, and payment handoffs. Everything else stays inside. On-prem with those disabled: nothing.
What happens if the internet goes down?
On-premises, the practice keeps working — documents, mail, search, tasks, local models, transcription. You lose only what genuinely lives outside: frontier calls and live court fetches.
How do updates work?
Versioned images with runbooks. Managed tenancies update on our schedule; private-cloud and on-prem update on yours. Database migrations are explicit and auditable — no silent schema drift.
How do users authenticate?
OpenID Connect against your firm's own identity realm, with MFA policy, role-based access, session limits, and optional IP binding. SSO is the architecture, not an enterprise add-on.
Can we monitor it ourselves?
Yes — the security and logging dashboards on the Security page are part of the product, and the log store is queryable and exportable. Health endpoints and service status are exposed for your own monitoring.
What does the AI cost us?
Every token is metered per model, attributed to firm, user, feature, and matter, and lands as a normal expense — with budgets and kill switches on standing work. There is no unmetered AI path.
How do we leave?
With your data. PostgreSQL is exportable; documents are standard DOCX/PDF in your storage; email is standard IMAP-accessible mail; invoices export as PDF and LEDES. No proprietary formats stand between you and the exit.
Bring your architect.
We'll walk through the deployment diagram, the egress list, and the exit path — with the engineer who built it.