ArkApps: one inventory for every application you run
Services, environments, owners, dependencies, running versions and health in a single catalogue, kept current by the platform rather than by whoever last remembered to update the wiki.
What is ArkApps?
ArkApps is the DevOpsArk application catalogue that tracks every service, its environments, ownership, dependencies, deployed versions and health in one inventory.
What ArkApps is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Nobody can say with confidence how many services the organisation runs, or who owns each one.
- The service catalogue is a spreadsheet, and the spreadsheet is nine months out of date.
- Finding which version of a service is in staging means opening a cluster and reading a manifest.
- When an incident starts, the first ten minutes go to working out who to page.
- Dependency questions such as "what breaks if we take the auth service down" are answered from memory.
ArkApps builds the catalogue from what is actually deployed rather than from what someone declared. It reads workloads out of connected Kubernetes clusters and servers, matches them back to the repositories and images that produced them, and infers the dependency graph from service-to-service traffic and configuration. Each application record carries its environments, the exact image digest running in each one, the owning team and escalation path, its runtime health, its open vulnerabilities and its recent deployments. Because the record is derived from live state, it does not drift: a service that is deleted disappears, and a service that appears without an owner is flagged rather than ignored.
What ArkApps does
The 8 capabilities that make up ArkApps.
Auto-discovered inventory
Applications are discovered from running workloads across clusters, servers and cloud accounts, then matched to their source repository and image.
Environment matrix
See development, staging and production side by side with the exact digest running in each, so version drift is visible at a glance.
Ownership and escalation
Every service carries an owning team, an escalation path and a contact, so paging decisions take seconds.
Dependency graph
Service-to-service dependencies inferred from traffic and configuration, with blast-radius view for planned changes.
Health rollup
Monitoring, alerting and vulnerability status rolled into one health state per application per environment.
Deployment history
Every release to every environment, with who approved it and what changed since the previous one.
Orphan detection
Workloads with no owner, no recent deployment or no source repository are surfaced rather than left to accumulate.
Service scorecards
Score each service against the standards you care about: probes configured, resource limits set, runbook present, no critical vulnerabilities.
How ArkApps fits together
Outcomes
- The catalogue is always current, because it is derived from what is running.
- Incident response starts with the owner already identified.
- Version drift between environments is visible without opening a cluster.
- Blast radius for a planned change is read from the dependency graph rather than estimated.
- Unowned and abandoned workloads surface instead of quietly costing money.
Using ArkApps, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Connect sources
Attach clusters, servers, cloud accounts and Git providers.
- 2Discover workloads
ArkApps enumerates running services and matches them to images and repositories.
- 3Assign ownership
Map teams to services; unowned workloads are flagged for triage.
- 4Build the graph
Dependencies are inferred from traffic and configuration.
- 5Score and monitor
Each service is scored against platform standards and tracked continuously.
Where teams apply ArkApps
Establish a real service catalogue
Replace the spreadsheet with an inventory that updates itself from live infrastructure.
Find the owner in seconds
Open the application record during an incident and page the right team immediately.
Track standards adoption
Use scorecards to see which services meet the platform baseline and which are drifting.
Find abandoned workloads
Surface services with no owner and no recent deployment, then decommission them.
What ArkApps works with
Named integrations link to their own page. The rest are supported runtimes and formats.
ArkApps: frequently asked questions
The 8 questions teams ask most often before adopting ArkApps.
ArkApps is the DevOpsArk application catalogue. It tracks every service the organisation runs (environments, owners, dependencies, deployed versions and health) in one inventory that is derived from live infrastructure rather than maintained by hand.
It reads workloads from connected Kubernetes clusters, managed servers and cloud accounts, then matches each one back to the container image and source repository that produced it. Nothing needs to be registered manually.
It covers the catalogue, ownership, scorecard and deployment-history parts of that idea, and it is populated from live infrastructure rather than from YAML that teams maintain. It is one module of a platform rather than a standalone portal.
From observed service-to-service traffic and from configuration such as service references and environment variables. Inferred edges are marked as inferred, so you can tell what was observed from what was declared.
A scorecard checks a service against the standards your platform team has set (probes configured, resource limits present, runbook linked, no unresolved critical vulnerabilities), and produces a single adoption view across the estate.
Yes. The environment matrix shows the exact image digest deployed to each environment, so drift between staging and production is visible without opening a cluster.
It is flagged as an orphan rather than hidden. Orphan detection also surfaces workloads with no recent deployment or no matching source repository, which are usually the first candidates for decommissioning.
Yes. Services running on managed servers and on cloud platform services are discovered alongside Kubernetes workloads and appear in the same inventory.
See ArkApps against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.