A small dependency-free Express middleware for request count, errors, and latency

A small dependency-free Express middleware for request count, errors, and latency

For a small Express app on a single VPS, I wanted answers to a few basic questions: is traffic changing, are 4xx/5xx responses rising, is latency creeping up, and how much CPU and heap is the process using?

Prometheus + Grafana can obviously handle this, but for this app I wanted something much smaller.

So I wrote a small helper that counts things where Express already sees every response and exposes them as JSON. It uses only Express and Node built-ins, with no SDK and no prom-client.

The core of it:

const { performance } = require("node:perf_hooks");

const METRICS_PATH = "/statlite/metrics";

const counters = {
  requestsTotal: 0,
  responses4xxTotal: 0,
  responses5xxTotal: 0,
  requestDurationSecondsTotal: 0,
};

function statliteMetricsMiddleware(req, res, next) {
  if (req.path === METRICS_PATH) return next(); // don't count the polls themselves

  const start = performance.now();

  res.once("finish", () => {
    counters.requestsTotal += 1;
    counters.requestDurationSecondsTotal +=
      (performance.now() - start) / 1000;

    if (res.statusCode >= 400 && res.statusCode < 500) {
      counters.responses4xxTotal += 1;
    }

    if (res.statusCode >= 500) {
      counters.responses5xxTotal += 1;
    }
  });

  next();
}

Register it before your routes, then add a GET /statlite/metrics route that returns the counters plus process.cpuUsage(), process.memoryUsage().heapUsed, and process.uptime().

Because the finish listener fires after later middleware runs, it sees the final status, including a 500 set by an error handler.

A few design notes:

  • Counters are cumulative, so the poller derives rates and average latency from deltas. The app keeps only running totals.
  • Heap is V8 heap used, not RSS or container memory.
  • CPU is CPU-seconds divided by wall-seconds since the previous snapshot, so it is expressed in cores.
  • Snapshot collection does no I/O.

Limitations:

  • It's single-process, with counters in memory. Cluster mode, PM2 clusters, and replicas each need their own target or aggregation.
  • It reports mean latency only, with no percentiles.
  • The endpoint is unauthenticated and meant to sit on a private network.
  • Connections aborted before a response finishes aren't counted.

For charting and history, I point a small tool I built, StatLite, a single binary with SQLite storage, at the endpoint. Disclosure: I'm the author of StatLite.

Example StatLite dashboard showing the kind of metrics this endpoint can feed. This screenshot is from a separate demo, not the Express example above

Full writeup with the complete helper, config, and a runnable demo:

https://pvrlabs.xyz/articles/lightweight-express-monitoring.html

Curious what people here use for small Express deployments. Do you still reach for prom-client + Prometheus/Grafana, use a hosted service, or keep something simpler?

reddit.com
u/fykup — 10 days ago
▲ 12 r/quarkus

Spring Boot vs Quarkus vs Micronaut with JDBC: memory, startup, and CPU

I ran a small comparison of equivalent Spring Boot, Quarkus, and Micronaut applications using JDBC rather than Hibernate/ORM.

All three used the same Java 25 runtime, H2 database, SQL, fixture data, request workload, and JVM flags. I ran them one at a time in the same 1 GiB / 2 vCPU Ubuntu VM, then did a separate run with all three together.

For the individual 15-minute runs:

  • Spring Boot: 4.90 s startup, 214.3 MiB median RSS
  • Quarkus: 2.25 s startup, 178.4 MiB median RSS
  • Micronaut: 2.54 s startup, 186.7 MiB median RSS

Quarkus had the lowest whole-run median RSS and reached readiness fastest. One interesting detail is that Quarkus and Micronaut converged quite closely later in the run: their final five-minute median RSS was 189.7 vs 189.4 MiB, and their sampled peaks were almost identical.

CPU usage was low for all three, so this isn't a throughput benchmark. It's mostly a look at the footprint of three equivalent small JVM applications under the same setup.

I also published the method, raw data, application sources, and analysis script so the numbers are inspectable:

https://pvrlabs.xyz/articles/spring-boot-quarkus-micronaut-jdbc.html

Experiment/data:
https://github.com/PVRLabs/experiments/tree/main/statlite/spring-quarkus-micronaut-jdbc

Curious whether these results line up with what people here see from Quarkus JVM deployments.

u/fykup — 10 days ago

How much does JPA/Hibernate cost a small Spring Boot app? I measured mine

I wanted to see how much of the footprint of a small Spring Boot app came from the conventional Spring Data JPA + Hibernate stack, so I built a simpler version using JdbcTemplate and compared the two.

Same Spring Boot 4.1.1, JDK 25, H2, JVM flags, dashboard workload, and monitoring endpoints.

Across two runs in reversed order:

  • JPA/Hibernate: ~237.0 MiB median RSS
  • JDBC: ~146 MiB
  • Difference: about 90 MiB (~38%)

Startup surprised me too. Time from process launch to the first successful dashboard response:

  • JPA/Hibernate: 8.1 - 8.8 s
  • JDBC: 3.9 - 4.2 s

This isn’t an isolated benchmark of Hibernate itself. The JDBC version also has a simpler persistence architecture and data model, so I’m comparing the complete application approaches.

For this kind of small app, though, JPA/Hibernate feels like more machinery than I need. I still see the value once the domain model and persistence requirements get complicated, but I’m increasingly reluctant to make it the default for small services.

Experiment, methodology, charts, and raw data:

https://pvrlabs.xyz/java-performance/experiments/spring-boot-jpa-vs-jdbc.html

For smaller Spring Boot apps, what do you usually reach for: JPA, Spring JDBC, jOOQ, MyBatis, something else?

u/fykup — 16 days ago

Added a StatLite recipe to TierHive — tested with Spring Boot on a 256 MB VPS

u/fykup — 1 month ago
▲ 82 r/java

I’ve maintained the same Java ETL tool for 20 years. I think it still fits one narrow gap.

I started Scriptella about 20 years ago and have maintained it ever since.

For a long time I had little time to do more than keep it working. Recently I’ve had more time to invest in it again, so I’ve been modernizing the database stack, testing it with current PostgreSQL, MariaDB and MySQL drivers, cleaning up old compatibility assumptions, and making sure it works well on modern Java. The baseline is Java 17, with JDK 25 compatibility.

Doing that made me ask a more basic question: does a tool like this actually still have a reason to exist in 2026?

I think there is one fairly narrow gap where it does:

SQL-centric data jobs that are too complicated for a couple of standalone scripts, but too small to justify a batch or ETL platform.

Scriptella keeps most of the actual work in SQL. A small declarative XML file wires together connections, queries and scripts.

For example, you can query PostgreSQL, take each resulting row and execute parameterized SQL against another database, mix in CSV/XML sources, or package the whole operation as a repeatable CLI job. It can also be embedded directly into a Java application.

There is no server, scheduler, job repository or visual ETL environment to operate.

That also means it is deliberately not the right tool for everything. If I needed robust restartability, retries and complex batch semantics, I’d use something like Spring Batch. For normal schema migrations, Flyway or Liquibase are usually a better fit. And if the transformation is mostly application logic rather than SQL, I’d probably just write code.

The interesting case is when the transformation really is mostly SQL and you just need a small amount of machinery around it.

After working on the project again, I was surprised that this particular gap still seems to exist.

I’m curious whether other Java developers still encounter jobs like this, and what you use for them today.

GitHub: https://github.com/scriptella/scriptella-etl

u/fykup — 1 month ago
▲ 124 r/quarkus+3 crossposts

Spring Boot vs Quarkus on a 512 MB VPS with JDK 25

I’ve been adding Quarkus support to StatLite, so I used it as an excuse to run equivalent Spring Boot and Quarkus apps side by side on a very small VPS.

Both ran the same workload with:

  • JDK 25.0.4
  • -Xmx80m
  • H2
  • the same JVM tuning
  • one 512 MiB VM with 256 MiB swap
  • one StatLite process monitoring both

The result was less straightforward than I expected.

Quarkus actually started with higher RSS: about 145 MiB vs 112 MiB for Spring Boot in one of the controlled observations.

After an hour under memory pressure, the relationship reversed: Quarkus was around 83 MiB RSS with ~33 MB heap used, while Spring was around 154 MiB RSS with ~50 MB heap used.

But RSS was hiding an important part of the story. Quarkus had about 91 MiB swapped out versus ~66 MiB for Spring, so Linux paging was doing a lot of work.

And 512 MB turned out to be too tight for running both reliably. In a later one-hour observation, after the earlier package-maintenance pressure had cleared, the machine exhausted its memory/swap margin and the kernel OOM-killed Spring.

So I wouldn’t read this as a clean “Quarkus uses X MB less than Spring” benchmark. My main takeaway was how quickly RSS stops being a useful framework comparison once the machine is under serious memory pressure.

Full write-up, measurements, JVM flags, and experiment record:

https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html

pvrlabs.xyz
u/fykup — 1 month ago

Teaching coding agents to use quieter, predictable CLI tools

I’ve been experimenting with giving coding agents small, purpose-built CLI tools instead of having them consume the normal human-oriented output from Maven, npm, Go, etc.

One example: a real Tape test run produced 1,476 lines / 136 KB of successful output. For the agent, the useful result was basically:

✓ tests passed

I saw similar reductions across Maven, Vitest, Jest, and Go workflows, typically 98–99.99% on successful runs.

That led to agent-scripts, a small local-first collection of CLI utilities. The main build/test wrappers are:

  • mvn-lite
  • npm-lite
  • go-lite

They use the normal underlying tools, but expose a much quieter interface for routine agent workflows. Success is compact; failures retain useful diagnostics and full logs.

There’s also a separate lite-tools Agent Skill that teaches supported agents when to prefer these commands. The commands and the skill are intentionally separate: the tools provide the behavior, while the skill provides discovery/instructions.

Install tools:

curl -fsSL https://raw.githubusercontent.com/ejboy/agent-scripts/main/install.sh | bash

Install the skill:

npx skills add ejboy/agent-scripts --global --skill lite-tools

Repo: https://github.com/ejboy/agent-scripts

Measurements and tradeoffs:
https://pvrlabs.xyz/articles/coding-agent-test-output.html

The design question I’m interested in: do you see value in giving agents wrapper tools with a predictable, bounded interface, or would you rather put instructions in AGENTS.md telling the agent how to invoke/filter the normal tools?

reddit.com
u/fykup — 1 month ago

Follow-up: Running the same Spring Boot app on a 256 MB VPS with JDK 25

Follow-up to my 512 MB Spring Boot experiment: I tried the same application on a 256 MB Alpine VPS.

JDK 21 struggled badly at this size, but with JDK 25 and a tuned 80 MB heap, the app plus lightweight monitoring completed a one-hour run without restarts or OOM kills.

Still not something I’d recommend for normal production, but the difference was interesting.

pvrlabs.xyz
u/fykup — 2 months ago

Tried TierHive for a low-memory Spring Boot experiment, really liked it

Someone on r/VPS recommended TierHive when I was looking for a flexible VPS for a low-memory Spring Boot experiment, so I gave it a try.

I used the 256 MiB plan with Alpine and managed to complete a one-hour Spring Boot + StatLite monitoring run. It was definitely a stretch configuration, but TierHive worked very well for the experiment.

Spring Boot + StatLite on the 256 MiB TierHive VPS.

I wrote up the results here:
https://pvrlabs.xyz/articles/spring-boot-256mb-jdk25.html

I’m also planning to add TierHive deployment recipes and documentation to StatLite, so it should become easier to get lightweight monitoring running on these smaller VPS configurations:
https://github.com/PVRLabs/statlite

reddit.com
u/fykup — 2 months ago
▲ 77 r/java

Spring Boot on a 256 MB VPS: JDK 25 made the experiment viable

I followed up on my 512 MB Spring Boot VPS experiment by trying the same application on a nominal 256 MiB Alpine VPS.

This is not Hello World. The app uses Spring Boot 3.5.5, MVC/Tomcat, JPA/Hibernate, file-backed H2, Actuator, scheduled GitHub polling, and outbound HTTP. StatLite was running alongside it and polling both Spring and itself.

The JDK 21 setup was too tight. With a 64 MiB heap it suffered severe GC/paging pressure and eventually became unresponsive.

The final JDK 25 configuration was:

-Xms16m
-Xmx80m
-Xss256k
-XX:+UseSerialGC
-XX:TieredStopAtLevel=1
-XX:ReservedCodeCacheSize=32m
-XX:+UseCompactObjectHeaders

On the same nominal 256 MiB VPS, with about 217 MiB visible to Alpine and a 512 MiB swapfile, that configuration completed the full one-hour observation:

  • 0 OOM kills
  • 0 service restarts
  • 72/72 bounded HTTP requests returned 200
  • Spring scheduled work continued
  • final Spring RSS: ~86 MiB
  • StatLite RSS: ~10 MiB
  • swap used: 184 MiB

JDK 25 run after the one-hour observation. Spring Boot stayed up, StatLite kept polling, final combined RSS was ~96 MiB.

There was still one Hikari Thread starvation or clock leap detected warning with a ~2m13s delay, so I would not call 256 MiB comfortable. For a real deployment I would still start at 512 MB RAM with some swap.

Also, this is not a compact-object-headers benchmark. The JDK version, heap ceiling, and several JVM settings changed together, so I can't attribute the improvement to that flag alone.

Full write-up and reproducible experiment files:

https://pvrlabs.xyz/articles/spring-boot-256mb-jdk25.html

reddit.com
u/fykup — 2 months ago

Running a Java Spring Boot app on a 512 MB VPS with lightweight monitoring

I wanted to see how a fairly representative Java Spring Boot application behaves on a very small VPS, especially the difference between configured heap and actual JVM process memory.

The test app uses Spring Boot 3.5.x, Spring MVC, JPA/Hibernate, H2, embedded Tomcat, Actuator, scheduled work, and outbound HTTP. I also kept lightweight monitoring on the same machine.

The original 256 MB configuration was too tight. With 512 MB RAM + 256 MB swap, the application completed the test reliably.

Full setup and measurements are in the linked article.

Since then I’ve also managed to get the same application working on a 256 MB VPS with swap using JDK 25 Compact Object Headers and tighter JVM settings. I’m preparing that as a separate follow-up experiment.

pvrlabs.xyz
u/fykup — 2 months ago
▲ 21 r/java

Spring Boot on a 512 MB VPS: what actually fits?

I wanted to see how small I could make a realistic Spring Boot deployment while still keeping basic monitoring on the same VPS.

I first tried 256 MB RAM, but that wasn’t really viable for the representative app I tested. With 512 MB RAM + 256 MB swap, the application and lightweight monitoring completed the experiment successfully.

StatLite monitoring the Spring Boot app during the 512 MB run.

One thing that stood out was the gap between configured heap and actual JVM process memory. Even with a small -Xmx, RSS was substantially higher once you include metaspace, native allocations, threads, code cache, etc.

I wrote up the setup, JVM flags, measurements, and what failed at 256 MB:

https://pvrlabs.xyz/articles/spring-boot-512mb-vps.html

Curious how this compares with what others are seeing on small JVM deployments.

reddit.com
u/fykup — 2 months ago

Spring Boot on a 512 MB VPS: How Lightweight Monitoring Still Fits

I wanted to see how far a representative Spring Boot stack could be pushed on a small VPS without turning it into an artificial minimal demo.

The test app uses Java 21, Spring Boot 3.5.5, JPA/Hibernate, file-backed H2, embedded Tomcat, Actuator, scheduled work, and outbound HTTP.

I tried five RAM/swap configurations. The one that completed a clean 60-minute run was 512 MB RAM + a 256 MB swapfile, using:

-Xms16m -Xmx64m -Xss256k -XX:+UseSerialGC

During that run:

  • 0 Spring Boot restarts
  • 0 monitoring restarts
  • 72/72 HTTP checks returned 200
  • Spring finished around 167 MiB RSS
  • StatLite finished around 12 MiB RSS
  • about 140 MiB RAM was still available
  • about 160 MiB swap was in use

StatLite monitoring the Spring Boot app on the same 512 MB VM.

One thing that stood out was the gap between heap size and actual JVM process size. -Xmx64m obviously did not mean a 64 MB process. The JVM heap was roughly 40–50 MB, while the entire Spring Boot process used much more RAM.

For monitoring, I used StatLite. Actuator already exposes the health and JVM/HTTP metrics, so StatLite just polls those endpoints and stores a small local history in SQLite. There is no additional Java monitoring agent.

I also tried 512 MB without swap. That run completed, but Spring was OOM-killed and restarted once during the observation window. StatLite stayed up and continued polling, which was actually a useful demonstration of why I wanted the monitor to remain a separate lightweight process.

I also tested 256 MB configurations, but for this application they were clearly stretch tests rather than something I would deploy.

Full write-up, all five configurations, JVM flags, screenshots, and reproducible demo:

https://pvrlabs.xyz/articles/spring-boot-512mb-vps.html

I’d be interested to hear how much RAM similarly small Spring Boot services use in production.

reddit.com
u/fykup — 2 months ago
▲ 6 r/vscode

Reviewing agent-generated code with an independent second model in VS Code

Coding agents have changed how I use VS Code. More of the implementation happens in an agent, and when it finishes I spend more of my time in Source Control reviewing the resulting diff.

One workflow I've found useful is to review the whole change with a different model from the one that implemented it.

I built a small VS Code extension called AI Badger to make that easier.

From the Source Control view, AI Badger: Copy All Changes for Review packages the current git changes, including staged and unstaged changes, additions, deletions, and bounded file context, into a structured review prompt.

Then you just paste it into ChatGPT, Claude, Grok, or another AI chat and ask for an independent review.

The basic workflow is:

  1. Agent finishes implementing a change.
  2. Open Source Control in VS Code.
  3. Click Copy All Changes for Review.
  4. Paste into a different AI model.
  5. If the reviewer needs an unchanged supporting file, use Copy File for AI from Explorer.

Nothing is uploaded automatically. AI Badger is local-first and clipboard-based, so you decide exactly what leaves the machine and which model receives it.

For more complicated reviews, there is also an optional CLI workflow where the reviewer can request specific missing repository context, but the normal VS Code workflow does not require the CLI.

VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=pvrlabs.ai-badger

Live interactive demo:
https://pvrlabs.xyz/aibadger/vscode-demo.html

Full workflow article:
https://pvrlabs.xyz/articles/reviewing-ai-generated-code-vscode-aibadger.html

I'm curious how other people are handling this now. When an agent changes several files, are you mostly reviewing the diff manually, asking the same agent to review itself, or handing the change to a second model?

u/fykup — 2 months ago
▲ 7 r/VPS

I built a lightweight self-hosted monitoring dashboard for small VPS deployments

StatLite showing application metrics and host CPU, memory, and disk usage

I run Spring Boot applications on small VPS instances and wanted basic monitoring without adding a full Prometheus/Grafana stack or sending telemetry to a hosted service.

So I built StatLite, a lightweight self-hosted dashboard that monitors host resources and Spring Boot Actuator metrics.

Current setup is intentionally pretty boring:

  • single Go binary
  • tracks host CPU, memory, and disk usage alongside application metrics
  • SQLite storage
  • roughly 10-15 MiB idle RSS in my testing
  • no external database
  • no telemetry service or account
  • metrics stay on the VPS
  • easy to move to another provider with the rest of the deployment

Right now the main integration is Spring Boot Actuator, so if an application already exposes Actuator metrics, StatLite can poll them without adding an agent or changing application code.

The goal isn't to compete with Prometheus, Grafana, Datadog, etc. Those are much more capable. I'm interested in the smaller case where you have one or a few VPS nodes and mostly want to know: is the app healthy, what is CPU/memory doing, are requests/errors increasing, and what happened over the last few hours or days?

I'm curious how people here handle this today.

For people running self-managed VPS instances, would something like this be useful? And outside Spring Boot, what applications or runtimes would you most want a lightweight dashboard like this to recognize out of the box?

GitHub: https://github.com/PVRLabs/statlite

reddit.com
u/fykup — 2 months ago
▲ 18 r/java

Monitoring Spring Boot Actuator on low-resource VPS nodes without running a second JVM

When running small Spring Boot applications on 1-2 GB VPS instances, a full observability stack can be a significant amount of additional infrastructure for what may be a fairly simple deployment.

Over the past few weeks, I've been looking at how to keep operational visibility lightweight when polling standard Spring Boot Actuator endpoints. A few trade-offs stood out:

  • Bound the data you ingest. Even a lightweight collector should not assume every management endpoint will always return a small response. I ended up putting an explicit 1 MiB limit on Actuator responses and collecting a focused set of metrics, such as JVM memory, threads, HTTP errors, health, and restarts.
  • Polling frequency matters. A 30-second default gives reasonably responsive health and JVM trends for small deployments without constantly polling the application. For more resource-conscious production setups, slower intervals are usually perfectly reasonable.
  • The monitoring process has a footprint too. On a 1-2 GB server, I would rather not dedicate another JVM or several monitoring services to basic operational visibility. StatLite typically stays under roughly 15-20 MB of memory, while using local SQLite for recent history.

I built a small open-source implementation of this approach called StatLite.

StatLite dashboard in action

It runs as a single Go binary or Docker container, reads standard Spring Boot Actuator endpoints, stores recent history in SQLite, and serves a self-contained dashboard.

The latest release also adds multi-platform Docker images, bundles all dashboard assets locally for offline and air-gapped use, bounds historical queries and Actuator responses, and pauses browser refresh when the tab is hidden.

GitHub:
https://github.com/PVRLabs/statlite

Technical write-up:
https://pvrlabs.xyz/articles/lightweight-spring-boot-monitoring.html

I'm curious how others handle observability for small or single-node Spring Boot deployments. Do you use a full Prometheus/Grafana or APM setup, Spring Boot Admin, custom scripts, or something lighter?

I'm also considering making StatLite useful beyond Spring Boot by providing a small generic Java metrics exporter for regular Java web applications. It would expose a focused set of JVM and application metrics that StatLite could consume without requiring Spring Boot Actuator. Would that be useful, or is Spring Boot coverage enough for the kinds of deployments where a tool like this makes sense?

reddit.com
u/fykup — 2 months ago

Successful build logs are context pollution. I built CLI filters that cut some agent-visible output by 99%+

One thing I keep seeing in agentic coding is that the model gets fed a lot of output that is technically correct but not very useful.

A successful Maven build can print hundreds of lines. Same with npm tests. For an agent, the useful result is often just:

PASS · 11.8 s

So I built a few small deterministic CLI tools around a simple rule:

Success should consume almost no context. Failure should preserve enough evidence to act without forcing a rerun.

The main tools:

  • mvn-lite: compact Maven builds and tests
  • npm-lite: compact selected npm verification/test workflows
  • repo-map: machine-local repo and tool discovery
  • html-screenshot: one-shot Chrome screenshots
  • launch-browser: reusable Chrome DevTools sessions

A few measured success-path reductions:

  • Spring Maven: 5,564 bytes / 70 lines → 16 bytes / 1 line
  • Scriptella Maven: 66,812 bytes / 928 lines → 17 bytes / 1 line
  • npm + Vitest: 2,260 bytes / 43 lines → 25 bytes / 1 line
  • npm + Tape: 136,262 bytes / 1,476 lines → 12 bytes / 1 line
  • npm + Jest: 2,491 bytes / 68 lines → 24 bytes / 1 line

The failure path is more interesting.

If you compress failures too hard, the agent often reruns the command just to see what broke, which defeats the purpose.

So failures keep the full raw log locally. Short failures are printed in full, while long ones get bounded, marker-aware diagnostics. The goal is not “minimum bytes at all costs”. It is minimum context required for the next useful action.

repo-map tackles a different kind of context waste. Instead of hardcoding machine-specific paths into every AGENTS.md, related repos can use stable aliases:

repo-map get orders-api

A frontend can resolve its backend, the backend can resolve the frontend, and shared helpers like mvn-lite, npm-lite, and html-screenshot can be discovered without repeating tool paths in every repo.

Everything is Bash, local-only, deterministic, with no LLM calls, API keys, telemetry, or background service.

Sometimes context engineering is simply not putting irrelevant data into the context window in the first place.

Repo: github.com/ejboy/agent-scripts

Curious how others here handle command-output policy for agents.

u/fykup — 2 months ago

StatLite v0.2.2: Docker image and host metrics for lightweight Spring Boot monitoring

I shared StatLite here a few weeks ago. Since then, v0.2.2 has added a published Docker image and native host metrics, so I wanted to share the updated version.

StatLite is a lightweight monitoring dashboard for small Spring Boot deployments. It runs as a single Go binary or Docker container, reads standard Spring Boot Actuator endpoints, and stores recent history locally in SQLite.

What’s new in v0.2.2:

  • Docker image: Try or deploy StatLite without installing the binary
  • Native host metrics: Track CPU, memory, and disk usage alongside application metrics
  • Self-monitoring demo: The default Docker setup starts by monitoring StatLite itself
  • No StatLite agent or application library: It reads standard Actuator health and metrics endpoints

You can try it with:

docker run --rm -p 127.0.0.1:9090:9090 ghcr.io/pvrlabs/statlite:latest

Then open:

http://127.0.0.1:9090

StatLite is intended for one or a few applications on a small VPS or single server, where Prometheus, Grafana, and Node Exporter may be more infrastructure than the deployment needs.

It provides visibility into application availability, JVM memory, HTTP errors, restarts, and host resource usage.

It is not intended to replace a full observability stack for Kubernetes, distributed tracing, complex alert routing, or long-term enterprise telemetry.

Write-up:
https://pvrlabs.xyz/articles/lightweight-spring-boot-monitoring.html

GitHub:
https://github.com/PVRLabs/statlite

How are you monitoring small Spring Boot deployments today? Are you using a full observability stack, Spring Boot Admin, custom scripts, or something lighter?

reddit.com
u/fykup — 2 months ago
▲ 63 r/AgentSkills+3 crossposts

I made a small Bash wrapper that reduces successful Maven output by 99.7%

Successful Maven builds can produce thousands of lines that mostly confirm routine lifecycle steps.

That output is noisy when working in a terminal, clutters CI logs, and becomes especially expensive when build output is passed to a coding agent.

I built mvn-lite, a small deterministic Bash wrapper that keeps successful Maven output to one line while preserving the original exit code and complete raw log.

On a real four-module application:

  • Standard Maven output: about 6,753 bytes
  • mvn-lite output: 16 bytes
  • Result: PASS · 3.944 s
  • Reduction: more than 99.7%

Failures still return a nonzero exit code and show bounded diagnostics, while the full unmodified Maven output remains available in the raw log.

For example, an invalid lifecycle error was reduced by 91.6% while retaining the actual Maven error.

There is no LLM summarization, API key, or Maven extension involved. It is just a local Bash wrapper with deterministic text extraction.

Source and script: https://github.com/ejboy/agent-scripts

Benchmark details and design notes: https://pvrlabs.xyz/articles/introverted-maven.html

I’d be interested in feedback on Maven failure cases where compact output could hide something essential.

u/fykup — 2 months ago

StatLite: ultra-light Spring Boot monitoring without Prometheus or Grafana

I built StatLite for small Spring Boot deployments where raw Actuator endpoints are useful, but a full Prometheus and Grafana stack feels excessive.

StatLite polls Spring Boot Actuator, stores metric history in local SQLite, computes restart-aware counter deltas, and serves a simple dashboard from a single Go binary.

Screenshot of a dashboard

It currently shows:

  • application and database health
  • request volume
  • 4xx, 404, and 5xx errors
  • average request latency
  • JVM heap usage
  • process CPU usage
  • uptime and detected restarts
  • polling failures and missing metrics

It is designed for solo developers and small teams running one or a few Spring Boot apps on small VPSes. In my testing, StatLite uses less than 10 MB of private memory.

It is intentionally not a Prometheus or Grafana replacement. It is a lightweight middle ground between raw Actuator JSON and a full observability stack.

GitHub: https://github.com/PVRLabs/statlite

I would be interested to hear which Actuator metric or chart you consider essential for a small production app. Feedback, bug reports, and GitHub stars are appreciated.

reddit.com
u/fykup — 3 months ago