Stop building your telemetry pipeline.
One lightweight agent finds your sources. Logpacer reads each one, structures it, and names every field for you. No parsers, no grok, no pipeline YAML, nothing to babysit. Pick what to keep. Every field is indexed and searchable.
- 01 Configure Set retention & compliance
- 02 Install Edgepacer finds your sources
- 03 Collect Pick sources, already parsed
- 04 Search Query logs, metrics & traces
Watch the demo
From raw lines to named & searchable fields.
Our co-founder Morten walks through the core of Logpacer: setting up collection for a source, and watching the data land already structured on the other side — no parser written, none to maintain.
How it works
Set up in four steps. Then it runs itself.
No pipeline YAML, no query language to learn, no agent to babysit. You declare intent; Logpacer does the wiring. Here's the whole thing.
01 — Configure
Set your preferences once.
Choose how long to keep logs and which compliance frameworks you answer to. Pick a preset and the right log categories come along — retention and audit handled, no per-source config.
Read the docs →Retention
90 days
Compliance presets
45 categories · 8 families covered
audit ✓02 — Install
One agent. It finds everything.
Drop Edgepacer onto a host or cluster — a single Rust binary, DaemonSet, sidecar or Windows Service. It discovers containers, log files, systemd units and Windows Event Log channels on its own. No manifests to edit, no source list to maintain. It runs at under 0.1% CPU and around 10 MB of memory, and buffers to local disk with delivery guarantees — so a network blip never costs you a line.
Read the docs →$ curl -fsSL logpacer.sh/install | sh
linux · windows · macos — amd64 & arm64
discovering sources across the fleet…
✓ 12 containers linux
✓ 9 journald units linux
✓ 6 event log channels windows
✓ 3 windows services windows
✓ 4 log files any
✓ on host metrics any
34 sources · metrics on · 0 config files
03 — Collect
Choose what to collect. It's already parsed.
You decide what's collected — application and system logs, per source. Nothing is collected behind your back. And there's no parser to write: Logpacer has already sampled each source, typed every field, and given it a clear, descriptive name. Pick your sources, glance at the result, collect.
Read the docs →checkout · sample → parsed
2026-06-03T12:04:02.880Z ERROR payment.authorize denied order=8842 gateway=stripe ms=30021
04 — Search
Then just search. It's all there.
You don't write a query — you build one. Pick a field, an operator and a value: that's a filter. Group by any field, add a metric, click a bar to narrow the window. Every field is indexed and nothing was sampled away, so the answer is in there.
Read the docs →It's actually that easy.
Start your pilotHost metrics
Nothing to instrument. It's already on.
The agent that collects your logs reports host metrics from the moment it starts — CPU, memory and disk, network and disk throughput, processes and TCP connections. No exporters to deploy, no scrape configs, no dashboard to build. It measures its own footprint on the same board, so you can always see what it costs you.
All vitals healthy · CPU 41% · Memory 30% · Disk 50%.
Host utilization
CPU
now · avg 40% · peak 46%
Memory
now · avg 30% · peak 31%
Disk
now · avg 50% · peak 51%
Throughput
Network I/O
Bytes per second · received vs sent
Received
829 KB/s
Sent
7.40 MB/s
Disk I/O
Bytes per second · read vs write
Read
0 B/s
Write
5.08 MB/s
Processes
Share of total in running state
Total
1,766
Running
19
TCP connections
High time-wait — short-lived churn
Established
42
Time-wait
838
Agent CPU
EdgePacer process CPU
CPU %
< 0.1
Agent memory
EdgePacer resident set size
RSS (MB)
8.8
host metrics · on by default · no exporter, no scrape config
Storage & search
Keep everything. Pay for almost nothing.
On the public log-parsing benchmark corpora — a deliberately compression-hostile worst case — our engine shrinks your logs, metrics and traces about 15.8× (6.68 GB of those benchmarks down to 424 MB), measured the honest way: raw bytes in, fully structured and searchable bytes out. The industry counts it from already-structured data and calls it 31.4×; we lead with the raw number. That's the floor, not the ceiling — real production logs repeat far more. A 736,000-line IIS access-log set came in at 112.7×.
Every field is indexed, so you never choose what to make queryable — all of it stays searchable. And because queries prune by time window, a scoped search only reads the slice it needs, so it stays fast as the data grows.
We built it this way on purpose: a featherweight agent and heavy compression so keeping everything never taxes your nodes or your storage. Your compute and your storage stay yours.
stored vs raw · the honest way
15.8×
measured range · raw → searchable
Why it's different
You pick the sources. Logpacer does the rest.
It structures itself
No grok patterns, no regex, no parsing templates. Logpacer reads each source, structures the data, and names every field clearly.
Formats never break you
A frontier log analyzer structures formats it has never seen. When a source changes, it re-derives the structure automatically. No parser to write. None to fix at 2am.
Keep all of it
Once a source is on, nothing is sampled away or dropped. Every event is kept and searchable: application logs, system logs, audit trail included.
Logs, metrics & traces
Application and system logs, host metrics out of the box, traces shipped off-host. One agent collects all of it.
OTLP-compatible
Speaks OTLP. Your existing instrumentation just works. No rip-and-replace, no new SDKs to adopt.
Your compute stays yours
One light agent. It runs around 10 MB idle, not the hundreds of megabytes (or gigabytes) other collectors demand. In internal testing it sustained around 500,000 lines per second on a single core (a conservative floor, not production-at-scale). The compute you pay for stays with your applications.
Bring one fleet. Watch it light up.
We're preparing our first pilots. Point Edgepacer at one cluster or a set of hosts and see your application and system logs flowing — collected, parsed and searchable — without a week of pipeline plumbing.
Questions
The honest answers.
How is this different from a legacy observability vendor? +
You don't build or tune the pipeline — no grok patterns or parsing rules to write, no per-source index or retention decisions, no query language to learn for setup. Logpacer reads your data, structures it, names every field, and keeps all of it. And here's the part the rest of the space doesn't do: it collects your application and system logs together, with a level of compliance and audit coverage no other observability tool offers. One agent for logs, metrics and traces; one place to search.
What happens when a log format changes? +
Nothing you have to act on. There's no parser to break — when a source's format drifts, Logpacer re-derives the structure automatically and your fields stay named. It structures formats it hasn't seen before, so a format you change tomorrow needs no work from you. Format changes stop being an incident.
Do I have to run storage, or decide what to keep? +
No. Logpacer stores your data for you — all of it. You don't size or operate storage, write per-source retention rules, or choose what to index. You set a retention window and the compliance frameworks you answer to; everything else is handled.
Where does my data live? +
In the EU. Logpacer runs on European infrastructure — Hetzner and Scaleway, across Germany, the Netherlands and France — and your telemetry stays in-region. You get data residency and sovereignty without operating storage yourself.
What is the agent written in, and how heavy is it? +
Edgepacer is written in Rust and ships as a single static binary you install as a DaemonSet or sidecar. It's genuinely light: in our own running fleet it sits at under 0.1% CPU and roughly 10 MB of memory. It discovers sources and ships raw logs, metrics and traces — parsing, structuring and storage all live downstream — and it buffers to local disk with delivery guarantees, so a network blip or backend hiccup replays instead of dropping a line.
Does it run on Windows? +
Yes — Windows, Linux and macOS, on amd64 and arm64. On Windows the agent installs as a Windows Service and discovers Event Log channels and Windows services on its own, exactly the way it discovers journald units and systemd services on Linux, with host metrics on every platform. That matters for audit coverage: if you answer to ISO 27001, SOC 2 or CFCS, a large part of your evidence trail lives in the Windows Event Log — and it gets collected, structured and named like everything else.
Just logs, or metrics and traces too? +
All three. Application and system logs — containers, journald, systemd units and /var/log — plus host metrics out of the box and traces shipped off-host. One agent discovers and collects them.
Do the compliance presets do the work for me? +
They make coverage legible: choose a framework — GDPR, ISO 27001, SOC 2 or CFCS — and the relevant log categories are grouped, with tags carried through to retention. It organises and documents your coverage; it doesn't replace your own compliance judgement.
Can I point an AI agent at my logs? +
That's the end goal Logpacer is built toward. Because every field is classified as it's ingested, we know which ones carry personal data — so the intent is that an agent can query across everything while PII is held back and never leaves the EU. We're building that interface now. It isn't live yet, and we won't pretend it is.
Who is behind Logpacer, and can I use it now? +
It's built by a small, independent team. We're preparing our first pilots — lining up a limited set of private-beta design partners. If that's you, request early access and we'll be in touch.