Four questions that usually decide it
Most organisations that end up self-hosting APM don't get there because of a feature. They get there because one of these questions has a firm answer.
Can this telemetry leave our network? Traces contain URLs and database statements. Logs contain whatever developers wrote. If your security or legal function has said no, or would take a year to say yes, a hosted service is out regardless of how good it is.
Do the monitored systems have a route out at all? In a closed network, agents can't reach an outside service. A backend inside the boundary is the only design that works without building an exception.
What happens to monitoring when the external link fails? If your WAN or internet connection is part of the outage, then a monitoring system beyond that link goes blind at the moment you need it. An inside backend keeps seeing inside systems.
Who decides when the software changes? Some change-managed environments require testing and approval before any production component changes. A vendor-managed release cycle may not fit that process, whereas self-hosted software changes when you schedule it.
If you answered "it doesn't matter" to all four, a hosted SaaS APM tool may well be the better option for you, and the next section explains why. The full side-by-side analysis is in on-premise versus SaaS APM.
When on-premise is the wrong choice
- You have no one to run it. A self-hosted backend needs an owner for upgrades, storage, backups and capacity. With a two-person team already stretched, this can be the wrong place to spend their time.
- Your workloads are in a public cloud with no restrictions on telemetry. Sending data out to a nearby managed service can then be the simplest choice, and hosting your own backend in the same place gains you little.
- You need global outside-in monitoring. A probe in your data centre cannot tell you how your site looks from another continent. A service with worldwide probe points does this naturally.
- You need to be running this afternoon on a sharply variable scale. Hosted services absorb sudden growth, and with your own backend, capacity is your problem. If your telemetry volume may multiply within a quarter, that's a real risk to plan for.
- Your scale is small and your data is not sensitive. Then a light tool may be enough, and an APM platform may be more than you need.
What you take on
These are the responsibilities that come with owning the backend. None is unusual for a platform team, but all of them are real.
| Area | Your responsibility | Practical note |
|---|---|---|
| Compute | Nodes or hosts for UI, API and analysis | The architecture diagram shows 3+ replicas |
| Storage | PostgreSQL capacity, performance, backups | Telemetry is write-heavy, so plan disks accordingly |
| Upgrades | Testing and scheduling releases | Handled through your own change process |
| Access | Identity integration, group mapping | OIDC, LDAP and scoped RBAC |
| AI (optional) | Hosting the model | Local model, can be off |
| Self-monitoring | Who monitors the monitor? | Have an independent check on the platform's availability |
The last row is easy to overlook. If your monitoring platform runs on the same cluster and the same storage as the things it watches, then a shared failure takes both out together. Where you can, place it in a different failure domain. At a minimum, use a simple independent check that tells someone when monitoring itself is not available.
Estimating storage: a worked example
We don't publish generic sizing numbers, since they would be misleading. Here is how you can get a first estimate from your own figures. All the inputs are invented for this example, and you should substitute real ones.
Suppose that after tail-based sampling you keep 64 traces per second, an average trace has 30 spans, and an average span is about 1 KB before compression.
64 traces/s × 30 spans × 1 KB = 1,920 KB/s ≈ 1.92 MB/s
1.92 MB/s × 86,400 s/day ≈ 165,888 MB/day ≈ 166 GB/day
166 GB/day × 14 days of retention ≈ 2.3 TBThree things to notice. First, the sampling decision moves this number more than almost anything else. Without sampling, at an example of 1,000 traces per second, the same arithmetic gives 2.6 TB per day. Second, span size varies a lot. A service that attaches long SQL statements can be several times bigger than the average. Third, that example excludes logs, which are often the largest source, and also indexes and compression, which pull in opposite directions.
Bring measured numbers and we can look at them together. Ask us at info@wrentrix.com.
How Wrentrix is deployed
Wrentrix runs on Red Hat OpenShift, Kubernetes and Linux servers. There are three installation methods:
| Method | Good for | Example |
|---|---|---|
| Helm chart | Kubernetes with Helm-based delivery | helm install wrentrix ./wrentrix.tgz -n wrentrix -f values.yaml |
| OpenShift operator | OpenShift teams who prefer operator lifecycle | Installed through your operator process |
| Docker Compose | One Linux host | Single-machine setup |
The platform runs under the default restricted-v2 SCC, with least-privilege
pods, no root and no extra SCCs. Storage is PostgreSQL. That combination matters in a
practical way, because a monitoring tool which needs a custom SCC or a privileged DaemonSet
usually enters a long security review. See restricted-v2 explained.
Connecting systems takes a few minutes per target:
- Add a cluster or Linux host in the UI.
- Download the ready-made YAML or install script. The token is inside it.
-
Apply it:
oc apply -f wrentrix-k8s-agent.yaml. - Nodes, pods and hosts appear in about two minutes.
- Java and .NET workloads get method-level tracing on their next restart. Wrentrix does not restart anything itself.
Existing OpenTelemetry investment carries over, since any SDK can send OTLP and existing collectors keep working. It means you can move at your own pace and keep instrumentation portable. Should you ever change backend, your instrumentation stays valid.
What an evaluation should look like
Try to answer the hard questions early, rather than discovering them after a purchase. A two-to-four-week plan could run like this:
- Week 1: security review and install. Hand over the YAML and the architecture to security. Check the SCC, the webhook configuration, the agent's RBAC and egress.
- Week 1-2: one real cluster. Pick a non-critical but realistic environment. Include a Java or .NET service, a Linux host, and a real dependency chain.
- Week 2: test the failure modes. Stop the agent, then create a pod and confirm it starts. Stop the backend and confirm that applications don't notice. Block outbound traffic and confirm nothing changes.
- Week 2-3: replay reality. Do a controlled failure, and have an engineer who hasn't seen the setup diagnose it. Time it.
- Week 3-4: measure the cost of owning it. How many hours did this take your team? How fast is storage growing? Measure the overhead on a representative service, and compare it with a run without instrumentation.
The live demo is a backend-less walkthrough with sample data. It's a useful way to get a feel for the screens before you commit a cluster, although it says nothing about how the product behaves on your own workload.
The data-control argument, stated carefully
Self-hosting gives you a clear answer to "where is this data?": on your hardware, in your network, with 0 bytes of telemetry leaving it. It doesn't, on its own, make any organisation compliant with anything. You still own access control, retention and the content of your logs. Requirements under frameworks such as KVKK, GDPR, BDDK rules or DORA depend on your situation, and the data residency page goes into that in general terms. This is not legal advice.
Frequently asked questions
What is on-premise APM?
It is application performance monitoring where the backend runs on infrastructure you control, not in a vendor's cloud. Your agents and SDKs send traces, logs and metrics to systems inside your network. You gain data control and independence from outside links, and you take on operating the platform.
Is on-premise APM more expensive than SaaS?
It depends, and we won't give a generic figure. Self-hosting shifts cost to hardware, storage and staff time, while hosted pricing usually grows with data volume or hosts. Do the comparison with your real volumes and include the engineering hours for both options.
Can on-premise APM run on OpenShift?
Yes. Wrentrix installs on OpenShift with an operator or a Helm chart, and it runs under the
default restricted-v2 SCC with no extra SCCs and no root. It also runs on
Kubernetes and on Linux servers.
How long does it take to set up?
After the platform is installed, adding a cluster or host takes a downloaded YAML or script, and nodes, pods and hosts appear in about two minutes. Method-level tracing for Java and .NET arrives when workloads next restart. Security review and storage planning usually take longer than the technical install.
Does using OpenTelemetry lock me in to a backend?
No, that is one of its main benefits. Wrentrix accepts standard OTLP, so instrumentation written with OpenTelemetry SDKs stays usable with any other OTLP backend. A collector can also send the same data to two backends during an evaluation.