Is my memory usage of the Dokploy app itself higher than it should be?

[Shragenator]

Hello all. I recently have made a Dokpoyment on a VPS for my backend for a webapp. Used docker compose, linked my github and have automatic updates based on changes in the repo. All looks great and was a smooth experience.

After I confirmed it was all set up and working, I ran my realtime resource moniter on the VPS. Was a bit surprised to find that it was using about 700mb to run. That seems quite a bit higher than I expected, as I heard Dokploy was quite lean.

The only deployments I am running are those 2 containers sourced from a docker compose, which seem to come out to about 225mb memory together.

Here's some data:

Memory usage from bpytop:
Dokploy | ~696 MB
Bun API | ~125 MB
Python workers | ~100 MB
Traefik | ~51 MB

sudo docker ps | grep 8e4c340401d4
8e4c340401d4 dokploy/dokploy:v0.28.8 "docker-entrypoint.s…" 10 hours ago Up 10 hours (healthy) 0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp dokploy.1.98ljqn2nmnwuc44syhpl81s8u

sudo docker stats dokploy.1.98ljqn2nmnwuc44syhpl81s8u --no-stream
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
8e4c340401d4 dokploy.1.98ljqn2nmnwuc44syhpl81s8u 3.87% 696.4MiB / 1.921GiB 35.40% 6.97MB / 17.8MB 642MB / 300MB 47

And yes, i know the VPS is quite small. will be upgrading the memory soon regardless.

Debian 12
Dokploy version (v0.28.8)

Happy to provide more info if needed.

[dosubot[bot]]

Hi @Shragenator! I'm Dosu and I’m helping the dokploy team.

Your ~700MB memory usage is within the expected range for Dokploy. On a fresh installation, Dokploy typically uses 450-465MB in idle state, and users have reported it can grow to around 950MB over time.

The memory consumption increased in v0.27.1 due to healthchecks that spawn a curl process every 10 seconds to perform database queries. This adds overhead from process spawning (~360 curl processes/hour), database connection pool activity, and memory fragmentation.

If you want to reduce memory usage, you have a few options:

1. Use a lighter health endpoint that skips the database query:

   healthcheck:
     test: ["CMD", "curl", "-fs", "http://localhost:3000/api/health"]
     interval: 10s

2. Increase the healthcheck interval (e.g., from 10s to 30s or 60s)

3. Disable healthchecks entirely by recreating the service with --no-healthcheck (saves ~50-100MB initially, but reduces reliability)

So in short — your usage is normal, not a leak or misconfiguration.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Shragenator]

@dosu what are the consequences of using the lighter health endpoint (option 1)?

[dosubot[bot]]

The main consequence is that /api/health won't detect database failures.

The default endpoint /api/trpc/settings.health executes a SELECT 1 query against PostgreSQL, so it validates database connectivity. If the database goes down or becomes unreachable, the healthcheck fails and Docker can restart the container.

The lighter /api/health endpoint just returns { ok: true } without any actual checks. It only confirms the HTTP server is responding.

What you'd miss:

• Database connectivity failures
• Database authentication/permission issues
• Connection pool exhaustion
• Network problems between the app and database

In practice, this means the container could show as "healthy" while unable to serve real requests because it can't reach the database.

The tradeoff: On a small VPS where memory is tight, the lighter endpoint reduces overhead. But if something goes wrong with your database connection, you won't get automatic recovery from Docker's health-based restarts. You'd have to notice the problem yourself through failed requests or monitoring.

For most production setups, the default endpoint is recommended despite the memory cost. But if you're memory-constrained and can accept the risk, the lighter endpoint is a reasonable option — just know you're trading off failure detection for lower resource usage.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[JezCruz]

You can check your memory usage by monitoring your containers using:

bash
docker stats

This will show real-time CPU and memory usage for each container.

Also, make sure you're not running unnecessary services in your docker-compose.yml file, as they can consume extra memory.

You can also try:

• Restarting the container to see if memory usage resets
• Checking logs using docker logs <container_name>
• Monitoring your VPS resources to ensure it's not system-wide usage

If the issue persists, it might be related to memory leaks in the application or misconfigured services.