AI and automation

Self-hosting VPS Sizing and Cost Calculator for AI Apps

Plan the first server size for n8n, Dify, or Open WebUI, then see the monthly run rate before you rent a VPS or GPU host.

When to use this

Use it before turning a local AI idea into a server bill

This calculator is for self-hosted automation, chat frontends, workflow apps, and small team AI stacks. It is a sizing screen, not a replacement for load testing or a provider quote.

Default result

The server-rendered Dify example recommends Basic 8 GB / 4 vCPU and estimates $57.60 per month with weekly backups.

App profile

Dify Docker Compose lists CPU >= 2 cores and RAM >= 4 GiB as minimum hardware requirements.

Retained data

0.9 GB logs plus 10 GB uploads

Storage includes a 20% planning headroom before tier selection.

GPU decision

External API or remote model

If you run local models, verify VRAM separately and enter the GPU host cost here.

Worked example: Dify team VPS sizing

The default Dify team app starts from the official Dify minimum of 2 CPU cores and 4 GiB RAM, then adds the standard workload headroom of 1 vCPU and 2 GiB RAM. With 8 users and 500 daily actions, the planning requirement is 3 vCPU and 6 GiB RAM.

Storage starts with the 50 GB Dify planning base, adds 10 GB of documents, and adds 500 actions x 30 days x 64 KB = 960,000 KB, or about 0.9 GB of retained execution data. With 20% headroom, that rounds up to 74 GB.

The smallest DigitalOcean Basic tier in the reference table that clears 3 vCPU, 6 GiB RAM, and 74 GB storage is the 8 GB / 4 vCPU / 160 GB tier at $48 per month.

Weekly backups at 20% add $9.60, so the default monthly estimate is $57.60 and the 12-month run rate is $691.20 before taxes, managed databases, GPU hosts, monitoring, email, domains, or engineering time.

How we size the VPS

The calculator starts from an app resource floor, adds workload headroom, then adds user and daily-volume pressure. It estimates retained execution storage from daily actions, retention days, and average retained data per action, then adds documents, local model files, and 20% storage headroom.

The final VPS recommendation is the smallest reference tier that clears the estimated CPU, RAM, and storage requirement. Monthly cost is VPS price plus backup percentage plus optional database and GPU host costs.

What size VPS do I need for Dify?

Dify has a higher floor than a simple web app because the Docker Compose stack includes multiple services and dependent components. The calculator starts with the official minimum, then moves the default team preset to a larger tier for practical headroom.

What size VPS do I need for n8n?

Small n8n installations can start lean, but production workloads should plan for execution data growth, backups, and Postgres. Queue mode and workers are a different scaling step, so use the database-cost input when you move beyond one simple container.

What size VPS do I need for Open WebUI?

Open WebUI as a front end can run separately from inference. If it only connects to external APIs or a remote model server, the VPS can stay modest. If you bundle local inference or use a GPU host, model storage, VRAM, and GPU cost dominate the decision.

When do I need a GPU server?

You need a GPU server when the model must run on your own infrastructure with acceptable latency and concurrency. If a hosted API or separate inference endpoint is acceptable, keep the web app VPS separate and size GPU hardware with a local model fit checker.

Reference data used by the defaults

Topic	Reference value	Source	Date	Note
Dify Docker Compose minimum hardware	CPU >= 2 cores and RAM >= 4 GiB	Dify self-host Docker Compose docs	As of June 2026	The calculator treats this as the minimum floor, then adds headroom for users, workload, logs, and documents.
Dify Docker Compose services	5 core services and 6 dependent components	Dify self-host Docker Compose docs	As of June 2026	This is why the default Dify preset starts above the minimum floor.
n8n production scaling signal	Queue mode provides best scalability; Postgres 13+ is recommended for queue mode	n8n scaling and queue mode docs	As of June 2026	Use the external database input when you split n8n across workers or managed Postgres.
Open WebUI deployment signal	Docker is officially supported and recommended for most users; cuda and ollama images are available	Open WebUI quick start docs	As of June 2026	GPU inference is not priced from this source; enter the GPU host price you are actually considering.
DigitalOcean Basic Droplet pricing	1 GB $6, 2 GB $12, 4 GB $24, 8 GB $48, 16 GB $96 per month	DigitalOcean Droplet pricing	As of June 2026	Verify region, taxes, promos, bandwidth, backups, and provider choice before budgeting.
DigitalOcean backup pricing	Backups can be 20% weekly or 30% daily of Droplet cost	DigitalOcean Droplet pricing	As of June 2026	The default calculator assumption uses 20% weekly backups.

The app sizing rules are a planning heuristic, not a vendor SLA. Replace all prices with the provider, region, backup policy, database plan, GPU host, and tax treatment you will actually use.

FAQ

Can I run n8n, Dify, or Open WebUI on the cheapest VPS?

Sometimes for a private test, but not always for a real team. Dify has a higher minimum floor, n8n needs more care as executions grow, and Open WebUI can become a separate GPU or inference-server decision when you stop using external APIs.

Why are the cost inputs editable?

VPS prices, regions, taxes, backup options, managed database fees, and GPU host prices change. The calculator includes a dated DigitalOcean reference table, but you should enter the quote you plan to buy.

Does the calculator include GPU inference cost?

Only if you enter it. The tool separates the web app control plane from GPU inference because local model hosting depends on model size, VRAM, concurrency, and the exact GPU provider.

When should I add Postgres or Redis?

Add Postgres when the app stores important production data or needs scaling. Add Redis or queue workers when n8n or Open WebUI needs multi-worker behavior, heavier concurrency, or safer background job handling.

Is this a replacement for load testing?

No. Use it to pick a first server size and budget range, then test your actual workflows, documents, models, traffic shape, and backup process before opening it to users.

What should I monitor after launch?

Watch CPU, RAM, disk usage, database size, queue depth, restart count, error logs, backup success, and response latency. Upsize before the system starts swapping or dropping jobs.

Decision path

What to do next

GPU fit