DEV Community: Few Servers

Why free, docker stats and ps disagree about memory on your VPS (measured on a 1 GB box)

Mortise Apps — Sat, 10 Oct 2026 14:00:00 +0000

You log in to a small server to see how much memory is left, and every tool gives a different answer. We ran the usual ones on our 1 GB test server within a minute of each other and wrote down what each said.

Short answer: They count different things. free reports the whole machine, and its available column (192 MB here) is the one that tells you how close you are to trouble. docker stats added up to only 343 MB because it leaves out swap and the cache the kernel can drop: n8n showed 24.6 MiB while another 195 MB of it sat in swap. Adding up ps RSS gave 904 MB, more than the 769 MB free called used, because pages shared between processes are counted once per process. For "am I running out", read free's available and the swap line; for "who is using it", read each container's cgroup files, swap included.

Measured 8 Oct 2026, 05:15 UTC, over SSH on our test droplet coolify-test (DigitalOcean FRA1, $6 Basic, 1 vCPU, 1 GB RAM, Ubuntu 24.04.5, kernel 6.8, Docker 29.8.2), up 6 days 15 hours. Twelve containers: Coolify 4.3.23 and its services, n8n 2.10.2 with Postgres, Uptime Kuma 2, a small Node app. Commands: free -m, /proc/meminfo, docker stats --no-stream, each container's cgroup memory.current, memory.swap.current and memory.stat, every process's /proc/<pid>/smaps_rollup, and vmstat 1 5.

The four answers, one minute apart

Tool	What it said	What it counts
`free -m`, used	769 MB of 961 MB	All RAM that is not free and not cache the kernel can reclaim
`free -m`, available	192 MB	What new programs can still get without swapping, by the kernel's own estimate
`free -m`, swap used	972 MB of 2,047 MB	Pages pushed out of RAM to the swap file
`docker stats`, all 12 containers added up	343 MiB	Each container's RAM minus its inactive file cache; no swap
`ps` / `smaps_rollup`, RSS of every process added up	904 MB	RAM pages each process can see, shared pages counted again for every process that maps them
`smaps_rollup`, PSS of every process added up	531 MB	The same pages, with each shared page split between the processes sharing it

Nothing here is wrong. Each line answers a different question, and the gaps between them are where people misread a server.

Why docker stats looks so small

docker stats takes the container's cgroup memory and subtracts the inactive file cache. For Coolify's main container the cgroup said 164 MB in use with 12 MB of inactive cache, and docker stats showed 152 MiB: the same number with the cache taken off.

What it never shows is swap. On a box that swaps, that is most of the picture (the cgroup files were read 17 seconds after docker stats, so small differences between the first two columns are memory moving in between):

Container	docker stats	In RAM (cgroup)	In swap (cgroup)
Coolify (app)	152 MiB	164 MB	242 MB
n8n	24.6 MiB	29 MB	195 MB
Uptime Kuma	45.6 MiB	47 MB	110 MB
BuildKit (left over from a build)	36.9 MiB	19 MB	62 MB
Coolify realtime	17.1 MiB	18 MB	51 MB
Coolify Postgres	19.0 MiB	26 MB	30 MB
Sample Node app	5.5 MiB	10 MB	29 MB
n8n Postgres	13.2 MiB	17 MB	26 MB

Judged by docker stats, n8n is a 25 MB app. Counting its swap, it is about 220 MB, nine times more. If you size a server from docker stats on a machine that is already swapping, you will undersize it.

To read both numbers for one container on Ubuntu 24.04 (cgroup v2), use the full container id:

id=$(docker inspect -f '{{.Id}}' n8n-container-name)
cat /sys/fs/cgroup/system.slice/docker-$id.scope/memory.current       # bytes in RAM
cat /sys/fs/cgroup/system.slice/docker-$id.scope/memory.swap.current  # bytes in swap

Why adding up ps gives too much

RSS is every page a process has in RAM, including pages it shares with others: libraries, and memory a parent process shares with its workers. Coolify runs PHP-FPM workers, and each one reported about 25-28 MB of RSS, but only 4.6-6.3 MB of PSS, its fair share once the shared pages are split. Add up the RSS of several such workers and you count the same shared memory once for each of them.

Across the whole machine, RSS added up to 904 MB and PSS to 531 MB. PSS is the better number for "how much does this group of processes cost"; RSS is the right number only for a single process on its own.

Per-process swap has the same trap. The Swap: lines in smaps_rollup added up to 1,583 MB, while the machine only had 972 MB in swap. Shared pages that were swapped out show up in every process that maps them. The biggest single entries were still useful for ranking: n8n's Node.js process (it appears as MainThread) with 187 MB, then uptime-kuma with 100 MB. Use per-process numbers to find the biggest users, not to add up a total.

Why free's used is not the number to watch

free called 769 MB used and 69 MB free, which looks alarming on a 961 MB machine. Linux keeps file cache in RAM until something needs the space, so free memory on a busy server is always low. The kernel's own estimate of what is still usable, MemAvailable, was 192 MB, and that is what free prints as available.

The swap line matters more on a small box: 972 MB of pages did not fit in RAM. vmstat 1 5 showed the kernel reading up to 180 KB per second back from swap in the one-second samples (0, 152, 128 and 180 KB/s; the first line, 464 KB/s, is the average since boot). Swap that sits still is harmless; swap that is read back all the time means the working set does not fit.

Which number to use for what

Am I about to run out? free -m: the available column, then the swap line. Low available plus a busy si column in vmstat 5 means it is time for more RAM.
Which container is the problem? The cgroup files above, RAM plus swap. docker stats alone hides swap.
Which process is the problem? Per-process RSS or swap, to rank them. Do not add them up.
What does a group of processes really cost? PSS, from /proc/<pid>/smaps_rollup.

The commands for the swap ranking are on our one-page checklist: find what is using memory and swap.

What this box should be

This is the same server we watched for 5 days with Coolify, n8n and Uptime Kuma. Six days in, it still runs, with about 1.7 GB of demand on 1 GB of RAM. The numbers above are why we would not judge it from docker stats: that view says 343 MiB and suggests plenty of room, while the machine is a gigabyte into swap.

If you are choosing a size for a similar stack, prices read on 7 Oct 2026: a DigitalOcean Basic droplet with 2 GB is $12 a month and 4 GB is $24; Database Mart's Express Linux VPS has 4 GB for $5.99 with a shared IP address and US data centres only (details in Database Mart VPS pricing explained). We measured only the 1 GB droplet in this article.

FAQ

Why does docker stats show less memory than free?

docker stats leaves out swap and subtracts the cache the kernel can drop, and it only covers containers, not Docker itself, the system services or the kernel. On our server the 12 containers added up to 343 MiB in docker stats while free said 769 MB used and 972 MB in swap.

Does docker stats include swap?

No. On our server n8n showed 24.6 MiB in docker stats and had 195 MB in swap at the same moment, according to its cgroup's memory.swap.current.

What is the difference between RSS and PSS?

RSS counts every page a process has in RAM, including pages shared with other processes. PSS splits each shared page between the processes that share it. Our PHP-FPM workers had about 25 MB of RSS each but 5 MB of PSS. Adding up RSS over-counts; adding up PSS does not.

Which free column should I watch?

available. It is the kernel's estimate of memory that new programs can use without swapping. free is always low on a busy server because Linux fills spare RAM with cache.

Why do the per-process swap numbers add up to more than the swap in use?

Swapped-out shared pages are reported by every process that maps them. Ours added up to 1,583 MB with only 972 MB of swap in use. Use the per-process numbers to rank, and free for the total.

Originally published on Few Servers. Some links there are affiliate links; we only cover what we measured.

The best MCP servers for Claude Code that need no API key: the 5 we ran

Mortise Apps — Fri, 09 Oct 2026 14:00:00 +0000

Most "best MCP servers" lists are a page of logos. This one has five servers, and we ran every one on 6 October 2026. None of them needs an account, a card or an API key. For each server we counted its tools, timed it and noted what to watch for.

Short answer: These five work in Claude Code with nothing but a terminal command: Context7 (current library docs, 2 tools), Playwright MCP (drives a real browser, 25 tools), Microsoft Learn (Microsoft and Azure docs, 3 tools, remote, nothing to install), Fetch (reads any web page as markdown, 1 tool) and Git (reads and writes a local repository, 12 tools). All five showed "Connected" in claude mcp list, and every test call worked. Playwright MCP is the heavy one: about 780 MB of memory with one page open, and 55% of the tool definitions in this list. Fetch can read internal URLs and Git can commit and reset, so add those two deliberately.

The 3-minute video version: 5 MCP servers for Claude Code with no API key (YouTube). In 30 seconds each: the five, with their tool counts and what to know about the Fetch server.

Tested 6 Oct 2026, 04:38 to 04:45 UTC: a MacBook (Apple silicon) with Node.js 20.19.4, Python 3.12 and uv 0.12.23; Claude Code 2.1.284. Each local server was started with the same command Claude Code uses. We then recorded its handshake, its tools/list reply and one or two real calls with a small MCP client of our own, measuring memory with ps. Then we added all five to Claude Code in a scratch project with the commands below and ran claude mcp list. No API keys or accounts were used anywhere.

The five, side by side

Server	What it gives Claude Code	Tools	Key or account	Started in (first run / again)	Memory	Version we ran
Context7	Current documentation for libraries and frameworks	2	None (optional key for higher rate limits)	6.8 s / 1.7 s	195 to 341 MB	4.1.1 (npm, MIT)
Playwright MCP	A real browser it can open, read and click	25	None	3.8 s / 1.5 s	332 MB, 778 MB with a page open	0.0.83 (npm, Apache-2.0)
Microsoft Learn	Search and fetch over Microsoft and Azure docs	3	None	0.5 s (remote)	none on your machine	server 1.0.0 (hosted by Microsoft)
Fetch	Any URL as markdown	1	None	10.8 s / 0.7 s	61 to 158 MB	2026.8.18 (PyPI, MIT)
Git	Log, diff, status, and also commit, branch and reset	12	None	4.3 s / 0.7 s	95 to 133 MB	2026.8.18 (PyPI, MIT)

"First run" includes npx or uvx downloading the package; "again" is the second start with the package cached. Memory is the server and its child processes, read with ps after the tool list (and, for Playwright, after opening a page).

The commands

Each line is the one we ran, in the form the project's own README gives for Claude Code (or, where it gives none, the standard claude mcp add form). They add the server to the current project only; add --scope user to make one available in every project.

claude mcp add context7 -- npx -y @upstash/context7-mcp
claude mcp add playwright npx @playwright/mcp@latest
claude mcp add --transport http microsoft-learn https://learn.microsoft.com/api/mcp
claude mcp add fetch -- uvx mcp-server-fetch
claude mcp add git -- uvx mcp-server-git --repository /path/to/your/repo

Fetch and Git are Python packages run with uvx, so you need uv installed. Context7 and Playwright need Node.js. Microsoft Learn needs nothing local: Claude Code talks to Microsoft's server over HTTPS.

1. Context7: library docs that are not two versions old

What it does: two tools. One finds the library you mean, the other returns documentation snippets for your question. We asked it to resolve "fastapi" for the question "How do I add a background task in FastAPI?". In 2.5 seconds it returned five candidate sources with their snippet counts, the top one FastAPI's own site with 3,457 snippets.

Without a key it worked for everything we tried. Its README says a key gives "higher rate limits and private repositories", and its API guide describes the no-key tier as "Low rate limits and no custom configuration" without giving a number (Context7 API guide, read 6 Oct 2026). We did not hit a limit in a handful of calls. Our full Context7 test graded three of its answers against ones we had checked by hand: two right, one incomplete.

Cost of keeping it connected: 4,937 bytes of tool definitions, about a quarter of Playwright MCP's.

2. Playwright MCP: a browser your agent can use

What it does: 25 tools that open pages, read them, click, type, fill forms, take screenshots and read the console and network. We opened fewservers.com/g/ and asked for a snapshot: the page loaded in 8.9 seconds (that includes starting headless Chromium) and the snapshot was 6,916 characters.

What to watch: it is the heavy one. With one page open, the server and its browser processes took 778 MB. Its 25 tool definitions are 21,332 bytes, more than the other four servers together. Our Playwright MCP test has the details, including the 32,732-character snapshot of a longer page and the find tool that keeps snapshots small.

3. Microsoft Learn: the remote one

What it does: three tools, microsoft_docs_search, microsoft_code_sample_search and microsoft_docs_fetch, over Microsoft's documentation. It runs on Microsoft's servers, so nothing is installed and nothing uses your memory. The handshake took 0.5 seconds.

We searched "Azure Functions Python timeout limit consumption plan". The answer came back in 1.2 seconds, 21,770 characters long. The first result was a Microsoft Q&A thread rather than a documentation page, so check which source an answer came from before relying on it. Use this one if you write code against Azure, .NET or Microsoft 365; skip it otherwise.

4. Fetch: any page as markdown

What it does: one tool, fetch, which downloads a URL and turns the HTML into markdown, in chunks if the page is long. Our article page came back in 3.4 seconds as clean markdown: breadcrumbs, intro, byline. A page that is mostly a form (our /g/ page) came back as two lines, because the extractor keeps the main text and drops forms.

What to watch:

It quietly needs Node.js too. When Node is installed, Fetch uses a JavaScript HTML simplifier and runs npm install on the first fetch. On our machine that first fetch failed with an npm cache permission error ("returned non-zero exit status 1"). With a clean npm cache it took 6.0 seconds the first time and 1.9 seconds after that. If your first fetch fails, look at npm, not at the server.
It can reach your internal network. Its README warns that it "can access local/internal IP addresses". Do not add Fetch on a machine that can see admin panels or cloud metadata endpoints you don't want an agent reading.
It obeys a site's robots.txt by default for requests the model makes.

5. Git: your repository, including the write commands

What it does: 12 tools. Seven only read: status, three kinds of diff, log, show and branch. Five change things: add, commit, create branch, checkout, and reset, which the server itself marks as destructive. On a three-commit test repository, git_log, git_status and git_diff_unstaged each answered in 0.02 to 0.04 seconds.

What to watch: Claude Code can already run git in its shell, with your permission prompts. The difference is that this server's tools are separate MCP tools, and an "allow" you give them applies to commit and reset too if you allow the whole server. Pin it to one repository with --repository, and allow the read tools only. Add it when you want git history in an agent that has no shell. In Claude Code itself it adds little. Its README also says it "is currently in early development" and that its tools may change.

Which ones to add

Context7 if you write code against any library that changes often. It is light and needs no key.
Microsoft Learn if you work with Microsoft or Azure. It costs you nothing locally.
Playwright MCP when the agent has to check a real page: a deploy, a form, a bug report with steps. Remove it when you don't need it: it is the largest tool list and the biggest memory user here.
Fetch only if you need the agent to read pages as markdown in a client without web tools, and never on a machine with sensitive internal addresses.
Git mainly for clients without a shell; in Claude Code, prefer plain git with permission prompts.

Each server's tool definitions are loaded into Claude Code's context, and together these five come to about 39 KB. If you only need two of them, add two.

All five are listed, with thousands of others, in our MCP server directory, built from the official MCP Registry and refreshed daily.

FAQ

Which MCP servers work in Claude Code without an API key?

Context7, Playwright MCP, Microsoft Learn, Fetch and Git all worked with no key and no account when we ran them on 6 Oct 2026. Context7 accepts an optional key for higher rate limits.

How do I add an MCP server to Claude Code?

Run claude mcp add <name> -- <command> for a local server, or claude mcp add --transport http <name> <url> for a remote one, then check it with claude mcp list. Add --scope user to use it in every project.

Which MCP server uses the most memory?

Playwright MCP, because it runs a real browser: 778 MB with one page open in our test. The others used 61 to 341 MB, and Microsoft Learn none, because it runs on Microsoft's servers.

Is the Fetch MCP server safe to use?

Its own README warns that it can reach local and internal IP addresses. Use it on a machine where that is acceptable, and keep Claude Code's permission prompts on.

Do these servers slow Claude Code down?

Each one adds its tool definitions to the context: from 1,161 bytes for Fetch to 21,332 bytes for Playwright MCP. Local servers also start with Claude Code, from under a second to about 11 seconds on a first run while the package downloads.

Deploy Coolify on a $6 VPS in 15 minutes, timed step by step

Mortise Apps — Sun, 04 Oct 2026 05:00:00 +0000

Coolify is the self-hosted alternative to Heroku, Vercel and Netlify: one server, a web UI, push-to-deploy for anything that runs in Docker. The project's own docs say you need 2 CPUs and 2 GB of RAM. We wanted to know whether the $6 DigitalOcean droplet (1 vCPU, 1 GB RAM, 25 GB SSD) is enough for a small team's side projects, so we installed it, timed every step and left it running.

Short answer: Yes, Coolify runs on DigitalOcean's $6 droplet (1 vCPU, 1 GB RAM) if you add a 2 GB swap file first. Measured on 1 Oct 2026: install script 172 s, first app deployed and answering in 210 s, build peak 720 MB RAM + 669 MB swap, idle footprint about 250 MB for Coolify itself. For more than two small apps, take the $12 plan.

Short version: it works, with one trick (a 2 GB swap file). The install script took 172 seconds, the first app was answering HTTP requests 210 seconds after clicking Deploy, and the measured steps from an empty account to a running app add up to just under 10 minutes (our wall clock said 23, because of a wrong base directory described below and a coffee). Memory after boot sat at 618 MB used with four containers healthy; the build peaked at 720 MB plus 669 MB of swap, which is why the swap file is not optional.

Watch it instead

The same steps as a 5-minute video, with the numbers on screen: Deploy Coolify on a $6 VPS in 15 minutes (YouTube). Two 30-second versions: the one number that decides 1 GB and the deploy that said Success while restarting.

What you need

A DigitalOcean account. New accounts need a payment method before the first droplet; the droplet is billed hourly ($0.009/h), so a one-hour test costs a cent.
An SSH key on your machine. If you do not have one: ssh-keygen -t ed25519 -f ~/.ssh/coolify.
About 15 minutes.

Step 1: create the droplet (1 minute)

In the DigitalOcean console choose Create → Droplets. Pick the region closest to you, then Ubuntu 24.04 (LTS) as the image.

Under Choose a Droplet Plan stay on Basic → Regular and pick the $6.00/mo plan: 1 vCPU, 1 GB RAM, 25 GB SSD, 1000 GB transfer. Skip the $4 plan: 512 MB is not enough for Coolify's four containers even with swap.

Under Authentication choose SSH Keys and add your public key. Do not use a root password; Coolify itself will later use SSH keys to talk to the server, and password logins are the first thing bots try.

Tick Improved Metrics and monitoring (free), give the droplet a name, and click Create Droplet. Ours showed a public IP after about 60 seconds.

Step 2: add swap (30 seconds)

This is the part that makes the 1 GB plan work. Log in and create a 2 GB swap file:

ssh root@YOUR_DROPLET_IP
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
free -m

Without swap the install still completes, but the first docker build of a real app pushes demand past 1 GB and the kernel kills a container. With swap the build gets slow instead of dying; we measured the peak below (669 MB of swap in use during the build).

Step 3: run the Coolify installer (172 seconds)

One command, from the official docs:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

We timed it with date before and after. On the $6 droplet in Frankfurt:

Step	What it does	Time
1-2	OS check, apt packages (curl, wget, git, jq, openssl), SSH config	6 s
3-4	Installs Docker 29 and configures the network pool	57 s
5-8	Downloads compose files, writes `.env`, creates the localhost SSH key	under 1 s
9	Pulls and starts Coolify, Postgres, Redis, the realtime server and the Traefik proxy	109 s
	Total	172 s

When it finishes it prints Your instance is ready to use! and the URL http://YOUR_DROPLET_IP:8000. Four containers are running:

coolify           Up (healthy)
coolify-db        Up (healthy)
coolify-redis     Up (healthy)
coolify-realtime  Up (healthy)

Memory right after the install: 618 MB used of 961 MB, swap 32 MB. Disk: 7.1 GB used of 24 GB (Docker images are the bulk of it).

Step 4: create the root account and finish onboarding

Open http://YOUR_DROPLET_IP:8000 in a browser. The first screen creates the root user; do this straight away, because until you do, anyone who finds the port can.

After the account, a three-step onboarding wizard asks where to deploy. Pick This machine (the droplet itself); Coolify connects to it over its own localhost SSH key, checks that Docker is running and creates "My first project" with a production environment. The wizard offers to provision new servers on Hetzner, Vultr or DigitalOcean from inside Coolify, which is how you add a second box later.

The whole wizard is four clicks and took us under a minute; it ends on a "Setup complete" screen with the server, the project and the Docker engine all green, and a Deploy Your First Resource button.

Step 5: deploy your first app

The resource picker lists a few hundred one-click services (Sonarr, Plausible, n8n, Uptime Kuma and so on) plus the generic sources: public Git repository, private repository, GitHub app, Dockerfile, Docker Compose, Docker image. We chose Public Git Repository and pointed it at Coolify's own examples repo, https://github.com/coollabsio/coolify-examples, with the base directory /javascript/runtimes/nodejs (a tiny Fastify server on port 3000). Coolify inspects the repo, proposes Railpack as the build pack and shows the branch, port and base directory for review.

Click Continue, then Actions → Deploy. The deployment log streams live:

We timed it from the Deploy click to the first HTTP 200 from the public URL: 210 seconds. That breaks down into about 100 s of pulling the Railpack builder and Node base images (first deploy only; later deploys reuse them), 60 s of npm install on a 1 vCPU, and 20 s to start the container and for Traefik to pick up the route. The second deploy of the same app took 1 min 52 s.

Coolify gives every app a working URL immediately, on the free sslip.io wildcard DNS: http://<app-id>.64.226.72.55.sslip.io. Ours answered {"hello":"from nodejs #2"}.

One honest mistake worth recording: on our first attempt we typed the base directory as /nodejs (the folder had moved in the repo). Railpack happily built an image from an empty directory, the deployment reported Success, and the container then restarted every few seconds because it had nothing to run. Check the runtime logs after your first deploy, not just the green badge.

What the build did to a 1 GB server

This is where the swap file earns its keep. Our sampler logged memory every five seconds during the build:

Moment	RAM used	Swap used	Load (1 vCPU)
Idle, Coolify only	618 MB	32 MB	0.5
`npm install` running	765 MB	498 MB	4.2
Image export, peak	720 MB	669 MB	7.0
App running, 5 min later	648 MB	478 MB	0.4

Without the 2 GB swap file, the peak would have been about 1.4 GB of demand on a 961 MB box: the kernel's OOM killer would have taken out either the build or Coolify's own database. With swap, the build was slow (load 7 on one core) but finished. The Fastify app itself uses 31 MB.

Is 1 GB enough? The verdict so far

Resident memory per container after the deploy, from docker stats:

Container	Memory
coolify (the app)	150 MB
coolify-proxy (Traefik)	38 MB
coolify-realtime	25 MB
coolify-db (Postgres)	23 MB
coolify-sentinel	9 MB
coolify-redis	7 MB
your app (Fastify)	31 MB
Total	283 MB

Coolify's own footprint is about 250 MB; the rest of the "used" figure is the kernel, Docker and page cache. Disk after one build: 11 GB of 24 GB (base images and the build cache are the bulk; Coolify's cleanup job reclaims the cache weekly).

So: for one or two small apps, a static site, or a private tool, the $6 droplet with swap is fine and we are leaving ours running. We will update this section with the 7-day numbers (memory trend, swap, any restarts) once we have them.

What the $6 plan cannot do

Build large Node or Rust projects on the server. Builds are the memory peak; for anything heavier than a static site or a small Express/Flask app, build elsewhere (GitHub Actions) and have Coolify pull the image.
Run a database per app comfortably. One Postgres is fine; three is not.
Survive a traffic spike without swapping. If an app matters, the $12 plan (2 GB) is the realistic minimum and still far cheaper than one Heroku dyno.

Cost comparison

Option	Monthly	Notes
DigitalOcean $6 droplet + Coolify	$6.00	Unlimited apps within the box, your own domain, free SSL via Traefik
DigitalOcean $12 droplet + Coolify	$12.00	The comfortable size for a small team
Heroku Eco dyno	$5 per app, sleeps	One app, sleeps after 30 min idle
Render starter	$7 per service	One service
Railway hobby	$5 + usage	Usage-based

For a team running three or four small services, a single Coolify box replaces $20-40 of PaaS fees. The trade: you own the updates and backups.

FAQ

Does Coolify work with 1 GB of RAM?

Yes, with a swap file. Coolify's own containers use about 250 MB; the problem is the build step, which peaked at 720 MB of RAM plus 669 MB of swap in our test. Without swap the kernel kills a container during the first real build. With a 2 GB swap file the build is slow but completes.

How long does the Coolify install take?

172 seconds on a $6 DigitalOcean droplet in Frankfurt, measured from running the official install script to the "Your instance is ready" message. Most of that is installing Docker (57 s) and pulling the Coolify images (109 s).

How much does it cost to run Coolify on DigitalOcean?

$6.00 a month for the droplet ($0.009 an hour), plus $1.20 a month if you turn on weekly backups. Coolify itself is free and open source. There is no per-app charge, so the cost does not change when you add a second or third small app.

Should I use the $4 droplet instead?

No. The $4 plan has 512 MB of RAM and 10 GB of disk; Coolify's images alone used 7 GB in our install and the four core containers need more than 512 MB before any app runs.

Which plan for a small team running several apps?

The $12 droplet (2 GB RAM, 50 GB SSD) is the realistic minimum once you run three or more services or any database next to your apps. It is still far cheaper than one dyno or service on a hosted PaaS.

Next steps

Point a domain at the droplet and set it in Coolify's settings; Traefik issues Let's Encrypt certificates automatically.
Enable DigitalOcean's weekly backups ($1.20/month on this plan) or Coolify's own S3 backups.
Lock the server down: which ports Coolify needs and which to close.
Wondering whether 1 GB is really enough? The docs versus what we measured.
Know what the droplet costs before the invoice arrives: DigitalOcean droplet pricing explained.
Read our Coolify vs Dokploy comparison once it is published; both ran on this same droplet.

Originally published on Few Servers.