The Management Tool is the internal console at mt.dataandmore.com that operations uses to run the entire customer fleet: deploy a new toolbox, push a version upgrade, watch CPU and disk, see which client owns which deployment, publish release notes, read logs, and check NPS. It sits one floor above the platform itself, looking down on every running instance.
One console, every toolbox, every client, one screen at a time.
354toolboxes managed
8sidebar surfaces
14API blueprints
6container services
Section 01Purpose
What the tool does
Every Data & More customer runs their own platform instance, the "toolbox": a self-contained set of microservices for ingestion, profiling, classification, policy and reporting. The Management Tool is the place from which an operator deploys those toolboxes, keeps them on the right version, watches their health, and ties them back to a paying client, a partner, a contract, a subscription and a renewal date.
Lifecycle
Deploy and upgrade toolboxes
Add a new server, push a new platform version, toggle auto-updates, download the toolbox SSH key or TLS certificate, retire an instance. Every action is one row in the Servers list.
Commerce
Tie toolboxes to clients
Each toolbox carries a client, a partner, a plan, a price, a start and renewal date. Subscriptions, payments (Stripe), CRM (HubSpot) and notifications are wired in.
Insight
See the fleet, not the trees
CPU, disk, RAM and source-ingestion rates per toolbox, plus aggregate views: classification drift, source health, logs, NPS surveys, release-note delivery.
Section 02Architecture
The container layout
The tool ships as a Docker Compose stack. NGINX terminates TLS in front; a Flask API and a Celery-style worker share the same image; a Vue 3 SPA serves the UI; RabbitMQ moves async tasks between API and worker; dm-notify sends email. Persistent state lives in the platform's shared Elasticsearch, reached over the same secure network as every other Data & More service.
Internal data pathPlatform read / writeStateful / shared substrate
Figure 01, docker-compose at a glance
Section 03Wayfinding
Eight surfaces in the sidebar
The left rail is the entire navigation. Each surface is one Vue view and one or more Flask blueprints behind it.
01
Servers
The toolbox fleet. The default landing screen for ops.
02
Sources
Per-toolbox source connectors, with scan / ingest / profile rates.
Plans editor, what each subscription tier includes.
05
NPS
Net Promoter survey analytics across the fleet.
06
Classification
Global classification dictionaries pushed to every toolbox.
07
Logs
Searchable audit / activity log across deployments.
08
Releases
Release notes that get delivered into customer toolboxes.
Section 04The fleet
The Servers list
This is what every operator sees first. 354 of 354 toolboxes, one row per deployment, with the filter rail on the left and a tight action row on the right. The mockup below is faithful to the live screen.
Figure 02, Servers list, faithful to the live screen
Columns
What each column tells you
Server ID, the deployment slug (aesp01, apcoa01tool01). Tool nodes end in toolNN, ES nodes in esNN.
Client name, the paying customer, linked back to Clients.
Version, the toolbox platform version (v26.4.14). Drives the upgrade flow.
CPU / Disk / RAM, live resource pills coloured green under threshold, amber over it.
Price, monthly hosting cost in euros.
Server type, the Hetzner instance (EX44, EX130-R, AX61-NVMe, AX102).
Actions, the per-row toolbar: open monitoring, redeploy, upgrade, restart services, download cert / SSH key, edit, delete.
Filters
Slice the fleet
Each filter on the left expands into a faceted list with counts. The most useful for ops are Server status (running, stopped, errored), Server version (which toolboxes are behind), Alerts (active monitor hits) and Updates enabled (which toolboxes opt-in to auto-update).
Every action on a toolbox maps to one HTTP route on the Flask API. The mapping is small and stable, which keeps the operator console predictable.
Action
Route
What happens
Open the fleet
POST /servers/table
Paginated query with search + filters, returns rows for the Servers list
Available toolboxes
GET /servers/available
The set this operator may act on, scoped by company / partner
On-prem only
POST /servers/on_prem
Filter to on-premise deployments for a named company
Build the filter rail
POST /servers/filter
Facet values; POST /servers/cascade for dependent filters
Open a toolbox
POST /servers/details
Single deployment + statistics chart for the chosen period
Get a single record
GET /servers/single/<id>
Just the deployment document
Deploy a new toolbox
POST /servers/single
Create a deployment record; the worker provisions the host and installs the platform
Upgrade or reconfigure
PUT /servers/single
Push a new version, change instance type, toggle auto-updates, change ownership
Retire
DELETE /servers/single/<id>
Remove the deployment from the registry; the worker tears down infra
Download cert
GET /server/single/download/certificate/<id>
Base64-decoded TLS certificate, served as octet-stream
Download SSH key
GET /server/single/download/ssh_key/<id>
Base64-decoded private key for direct host access
Deploy
Adding a new server
Click + Add Server in the top-right of the Servers list. The form (ServersAdd.vue) collects: client name, partner, instance type, location, business stage, server version, alert thresholds, updates-enabled toggle. On submit, POST /servers/single creates the deployment record. The worker picks the task up off RabbitMQ and provisions the host (Hetzner Cloud), installs the docker stack and registers the new server back into the registry. Operator gets an email through dm-notify when it is live.
Upgrade
Pushing a new version
Filter Servers by Server Version to see which deployments are behind. From the row's action toolbar, choose Upgrade; the client calls PUT /servers/single with the target version. The worker pulls the new platform image on the toolbox host, runs migrations, restarts services. Updates enabled on a row lets the toolbox opt in to scheduled upgrades, so ops only has to nudge the laggards.
Section 06Adjacent surfaces
Clients, sources, releases, logs
The other sidebar surfaces follow the same pattern as Servers: a filter rail on the left, a search bar in the header, an actions column on the right, and a Flask blueprint behind each one.
Clients
The commercial view
Columns: Company name, Server ID, Start, Renew, Type, Users, MRR, Next notification, NPS. Filters by alerts, country, partner, MRR, plan type, start / renew date, status, user limit. Export to Excel and + Add Client in the top-right. Plans live behind Policy; payments via Stripe; CRM sync to HubSpot.
Sources
Per-toolbox connectors
Columns: Server ID, Source name, Source ID, Workspace, Source type, Scan/h, Ingest/h, Profiled/h, Updated at, Profiled, Total. Filters by server, workspace, type, partner. Toggle Hide inactive sources to focus on what is moving.
Releases
Release notes for the fleet
Operators publish release notes here that flow back into the customer-facing tools. Filters by Type, Tags, Version, Deployment ID, Instance type, Deployment type, Location. Sort by Newest first. + Add New Release opens the editor. The seed_release_notes.py script seeds defaults.
Logs
Searchable activity
Filters by username, workspace, deployment id, type, partner id. Date / time range plus a full-text search box. The case-log surface (case_log blueprint) sits adjacent for higher-level operator notes per client.
Quieter surfaces
Policy, the plans editor (EditPlans.vue): what each subscription tier costs, which features it unlocks, used by Clients.
NPS, the NPS analytics view (NPSAnalytics.vue): score trend across the fleet, per-client breakdowns, drives Next notification on Clients.
Classification, the global classification view (GlClassification.vue): dictionaries and rules pushed centrally to every toolbox so terminology stays consistent.
Section 07Relations
How it sits above the rest of the platform
The Management Tool is one floor up from every other Data & More service. It does not classify documents, scan inboxes or talk to Microsoft 365; it tells the toolboxes that do. Those toolboxes are the platform repos: api, client, iam, java_profiler, ai-profiler, dlp, ocr, graph-ingestion, ews, google, fileshare-service, known-persons-service, plus the data tier (Elasticsearch, PostgreSQL, RabbitMQ, Redis, S3).
Control plane, ops, to toolboxTelemetry, toolbox, to opsThe console
Figure 03, the management tool, one floor above 354 toolboxes
Section 08API surface
The 14 Flask blueprints
The API is one Flask app with 14 blueprints registered at boot in app.py. Each blueprint groups a small set of routes for one surface. The names map cleanly to the sidebar.
servers
fleet list, details, create, update, delete, cert and SSH download
clients
company records, plan, MRR, renewal, notifications
Vue 3 SPA, Vuex store, custom SCSS, mounted under services/client
API
Python, Flask, served by waitress in production via waitress-serve --call env:configure
Worker
Same Python image, .Dockerfile.worker entry, async tasks via RabbitMQ
Queue
RabbitMQ, AMQP, hostname rabbit
Notify
dm-notify (ECR image), email + alerts at :8002
Edge
NGINX, TLS terminator, reverse proxy on :80 / :443
State
Elasticsearch on monitor.gdpr.dataandmore.com, plus Prometheus for metrics, plus the platform IAM service for JWT keys
Commerce
Stripe (payment), HubSpot (CRM)
Network
External Docker network dm, shared with every other Data & More service
Local run
docker-compose -f docker-compose.local.yml up -d --build
Repo
github.com/dataandmore/management-tool
In one lineThe shape of it
One console. 354 toolboxes. Every move on the record.
The Management Tool is the operator's seat at Data & More: the place from which every customer toolbox is born, kept current, watched, billed and (eventually) retired. The platform does the work; this is where the people who own the platform see and steer it.
github.com/dataandmore/management-tool, served at mt.dataandmore.com