DEV Community: HostingSift

VPS Price Per GB of RAM: 711 Plans Across 39 Hosts

HostingSift — Mon, 31 Aug 2026 11:32:21 +0000

A gigabyte of RAM on a virtual server costs \$0.47 per month. It also costs \$58.00 per month. Same unit, same billing period, both prices live on 31 August 2026.

We priced every plan in our database that publishes a RAM figure: 711 active VPS and cloud plans from 39 providers, EUR prices converted to USD, everything normalised to dollars per gigabyte per month. The median came out at exactly \$6.00. Half the market sits above that line, half below, and the distance between the two ends is 123x.

That spread is not a mistake, and it is not all margin either. But it is far wider than most buyers assume, and the reason it stays wide is that almost nobody prices RAM by the gigabyte when they shop. They look at the plan name and the monthly figure.

How we counted

Every number here comes from our nightly price readings, taken on 30 and 31 August 2026. The rules we applied:

Only plans currently active and in stock, with both a price and a stated RAM figure. VPS and cloud categories, no shared hosting, no dedicated metal.
Prices converted to USD at our stored rate for the eight EUR-billed hosts in the set (Contabo, Hetzner, Netcup, OVHcloud, Private Hosting, Diploi, Evolution Host, Time4VPS).
Monthly-equivalent pricing. A 24-month Contabo term shows as its per-month figure, which is how the provider advertises it.
Railway's Pro plan is excluded. Its 1 TB figure is an account ceiling rather than provisioned memory, and including it would have handed the crown to a plan that does not give you a 1 TB server.
Fly.io's storage and bandwidth are usage-based and not counted against the RAM price.

The cheapest gigabyte at each host

For every provider we took its single best plan by dollars per GB, then looked up what that same plan renews at. The renewal column is where the ranking falls apart.

Provider	Best plan	RAM	Price/mo	\$/GB intro	\$/GB renewal
Contabo	Cloud VPS 18	96 GB	\$45.08	\$0.47	\$0.47
Time4VPS	Container C16	16 GB	\$8.06	\$0.50	\$1.01
NameHero	Business VPS	32 GB	\$20.68	\$0.65	\$1.50
IONOS	VPS XL+	16 GB	\$11.00	\$0.69	\$2.75
OVHcloud	VPS-6 2026	96 GB	\$71.35	\$0.74	\$0.74
Hostinger	KVM 4	16 GB	\$12.99	\$0.81	\$1.81
Netcup	VPS 8000 G12	64 GB	\$55.14	\$0.86	\$0.86
HostGator	Snappy 2000 NVMe 4	4 GB	\$4.18	\$1.04	\$2.34
HostArmada	Unmanaged Ignition	16 GB	\$16.89	\$1.06	\$2.64
DreamHost	Stack 16	16 GB	\$17.49	\$1.09	\$1.66
ServaRica	NVMe Cheetah	6 GB	\$7.00	\$1.17	\$1.17
InMotion Hosting	VPS 8 vCPU	16 GB	\$19.99	\$1.25	\$3.56
Private Hosting	VPS-RAM-64GB	64 GB	\$91.99	\$1.44	\$1.44
InterServer	1 Slice	2 GB	\$3.00	\$1.50	\$1.50
Bluehost	NVME 8	8 GB	\$12.99	\$1.62	\$3.62
A2 Hosting	Self Managed Linux L	32 GB	\$54.98	\$1.72	\$3.44
GoDaddy	32 vCPU / 128 GB	128 GB	\$219.99	\$1.72	\$2.66
Namecheap	Hypernova	24 GB	\$46.88	\$1.95	\$2.20
LiquidWeb	VPS 4GB (Self-Managed)	4 GB	\$8.50	\$2.12	\$4.25
Linode	High Memory 24GB	24 GB	\$60.00	\$2.50	\$2.50

Below that group the numbers climb quickly. AWS Lightsail's best memory ratio is \$4.50/GB, Hetzner's cloud line \$4.67, Vultr \$5.00, DigitalOcean \$5.25. Cloudways cannot get under \$9.66 and SiteGround's cloud entry point works out at \$12.50 per GB.

Contabo taking first place surprises nobody who has shopped European VPS before. What surprises people is second place: Time4VPS, a Lithuanian host most buyers have never heard of, selling 16 GB containers for \$8.06 a month. Its catch is in the renewal column, where the price doubles.

Renewal reshuffles the whole board

Twelve of the 39 hosts charge exactly what they advertise, forever. The rest use an intro rate, and the size of the step varies enormously.

IONOS runs the steepest one in the set. VPS XL+ is the fourth cheapest gigabyte in the market at signup and drops to sixteenth once the first year ends, because \$11.00 becomes \$44.00. That is a 4x step on a plan whose specs do not change. IONOS is far from alone: InMotion Hosting moves from twelfth to twenty-first, HostArmada from ninth to seventeenth, A2 Hosting from sixteenth to twenty-second.

Movement runs the other way too. OVHcloud is fifth cheapest at signup and second cheapest at renewal. Netcup goes from seventh to third. InterServer, whose flat \$1.50 per GB looks unremarkable next to Contabo's \$0.47, climbs from fourteenth to eighth simply by not raising anything.

Provider	Rank at signup	Rank at renewal	Move
OVHcloud	5	2	+3
Netcup	7	3	+4
ServaRica	11	5	+6
InterServer	14	8	+6
Time4VPS	2	4	-2
NameHero	3	9	-6
HostArmada	9	17	-8
InMotion Hosting	12	21	-9
IONOS	4	16	-12

Contabo holds first place in both columns. So does its price, which is the entire argument for buying there.

If you want to see what a specific step costs you over a full term rather than a month, our true cost calculator does that arithmetic, and we went deeper on the pattern in monthly vs annual vs 3-year plans.

What 8 GB actually costs, host by host

Ratios are useful for ranking. For a buying decision you want a fixed basket, so here is the same question asked concretely: what does an 8 GB server cost, and what else comes with it?

Provider	Plan	vCPU	Storage	Price/mo	Renews at
Time4VPS	Container C8	3	100 GB SSD	\$5.04	\$10.07
Contabo	Cloud VPS 4	4	100 GB SSD	\$5.06	\$5.06
IONOS	VPS L+	4	240 GB NVMe	\$6.00	\$21.00
OVHcloud	VPS-1 2026	4	75 GB NVMe	\$6.35	\$6.35
NameHero	Plus VPS	2	100 GB NVMe	\$6.85	\$15.92
HostGator	Snappy 4000 NVMe 8	4	200 GB NVMe	\$8.36	\$18.70
Hostinger	KVM 2	2	100 GB NVMe	\$8.99	\$14.99
DreamHost	Stack 8	2	150 GB NVMe	\$10.99	\$16.99
Netcup	VPS 1000 G12	4	256 GB NVMe	\$11.93	\$11.93
InterServer	4 Slices	2	160 GB SSD	\$12.00	\$12.00
Bluehost	NVME 8	4	200 GB NVMe	\$12.99	\$28.99
Private Hosting	VPS-RAM-8GB	2	50 GB NVMe	\$14.94	\$14.94
A2 Hosting	Self Managed Linux S	4	160 GB NVMe	\$19.99	\$39.99
LiquidWeb	VPS 8GB Self-Managed	4	240 GB SSD	\$22.50	\$45.00
Vultr	CC Regular 4vCPU/8 GB	4	160 GB SSD	\$40.00	\$40.00
Hetzner	CPX32	4	160 GB NVMe	\$40.81	\$40.81
DigitalOcean	Basic Regular 8 GiB	4	160 GB NVMe	\$48.00	\$48.00
Linode	Shared Linode 8GB	4	160 GB SSD	\$48.00	\$48.00
Cloudways	DO Basic Large	4	160 GB NVMe	\$99.00	\$99.00
SiteGround	Jump Start	4	40 GB SSD	\$100.00	\$100.00

Look at the bottom four rows against the top four. Cloudways charges \$99 for a DigitalOcean droplet that DigitalOcean sells for \$48, and the \$51 difference is the managed layer: patching, staging, a control panel, support that answers. Whether that is worth 2x depends entirely on how many hours of your own time you were planning to spend on server administration. We took that question apart in managed vs unmanaged VPS.

SiteGround's Jump Start is the one row that resists any justification on the numbers. \$100 for 8 GB and 40 GB of disk is 20x Contabo's rate for the same memory and less than half the storage.

Bigger boxes do not get you cheaper RAM

Standard intuition says memory gets cheaper per gigabyte as you scale up. Across the whole market that intuition is wrong.

RAM size	Plans	Median \$/GB	Cheapest \$/GB
Under 4 GB	104	\$7.14	\$1.45
4 GB	89	\$6.50	\$0.83
8 GB	105	\$6.00	\$0.63
16 GB	102	\$5.99	\$0.50
32 GB	79	\$5.81	\$0.65
64 GB	53	\$6.09	\$0.53
96 GB and up	91	\$6.91	\$0.47

The median barely moves from 4 GB to 64 GB, and at the top of the ladder it goes back up. Meanwhile the cheapest available rate keeps falling. Both facts are true because the volume discount is real inside certain hosts and absent at others, and the ones without it dominate the large-plan population.

Ranked by how much cheaper a provider's largest plan is per gigabyte than its smallest:

Provider	Smallest plan \$/GB	Largest plan \$/GB	Discount
Private Hosting	\$5.74 (1 GB)	\$1.44 (64 GB)	4.0x
HostArmada	\$3.69 (1 GB)	\$1.06 (16 GB)	3.5x
Time4VPS	\$5.10 (0.5 GB)	\$1.60 (64 GB)	3.2x
OVHcloud	\$2.02 (2 GB)	\$0.74 (96 GB)	2.7x
Contabo	\$1.26 (4 GB)	\$0.47 (96 GB)	2.7x
GoDaddy	\$4.50 (2 GB)	\$1.72 (128 GB)	2.6x
Hostinger	\$1.62 (4 GB)	\$0.81 (32 GB)	2.0x
DigitalOcean	\$8.00 (0.5 GB)	\$6.19 (384 GB)	1.3x
InterServer	\$1.50 (2 GB)	\$1.50 (16 GB)	1.0x
Vultr	\$5.00 (0.5 GB)	\$5.00 (256 GB)	1.0x
SiteGround	\$12.50 (8 GB)	\$20.00 (20 GB)	0.6x
Kamatera	\$4.00 (1 GB)	\$7.88 (8 GB)	0.5x
Fly.io	\$7.76 (256 MB)	\$15.50 (32 GB)	0.5x

Vultr and InterServer sell memory at a perfectly linear rate. Their pricing pages are honest in a way that makes comparison shopping trivial, and it means there is zero reward for over-provisioning.

The last three rows are the interesting ones. At Kamatera, Fly.io and SiteGround, scaling up costs you more per gigabyte, not less. Fly.io's Performance tier at \$15.50 per GB against its own \$7.76 shared tier is a dedicated-vCPU premium, which is the honest explanation. It is still a price signal worth reading before you scale a Fly app upward on autopilot.

Why cheap RAM is cheap

Contabo's \$0.47 and DigitalOcean's \$5.25 are not the same product wearing different price tags. Four things account for most of the gap.

CPU allocation. Budget hosts oversubscribe cores heavily. Contabo's 96 GB plan comes with 24 shared vCPU on EPYC silicon and you will feel the neighbours under sustained load. Hetzner's CCX line and Vultr's Optimized range give you dedicated cores, which is why their per-GB numbers look terrible. They are not selling you memory. Memory is a side effect of selling you a core.

Network. Contabo, Netcup and OVHcloud market unlimited or unmetered transfer at consumer speeds. DigitalOcean and Linode meter it precisely and charge overages. Our data shows Hostinger's KVM 4 including 16 TB of transfer while Vultr's 8 GB plans cap at 5 to 6 TB.

Support. A \$5 Contabo ticket goes into a queue. LiquidWeb answers in minutes and staffs Linux engineers around the clock. That difference is roughly half the price of a managed plan.

Recovery time when something breaks. This one never shows up in a spec table and matters more than the rest combined once you are hosting anything that earns money.

None of that makes \$12.50 per GB defensible at SiteGround. It does make \$5.25 per GB defensible at DigitalOcean if you use the API, the managed databases and the load balancers that come with it. Choose the tier that matches how you actually operate, then compare inside it: Contabo against OVHcloud for the European budget end, DigitalOcean against Hostinger when you are weighing a developer cloud against a value VPS.

These prices barely move

We have been recording VPS prices every night since 12 February 2026, which lets us answer a question nobody else can: how stable is any of this?

Very. Of the 185 plans in this analysis that we have been reading since mid-February, 165 have shown the same price on every single nightly reading. That is 89% of the sample frozen for six and a half months.

The stability is concentrated at the top of the market. DigitalOcean has not changed a single price on any of its 90 plans since we started watching. Linode has not moved on 39 plans, AWS on 25, Hostwinds on 40, Cloudways on 60. OVHcloud's entire 41-plan catalogue has held since we picked it up on 1 April 2026.

The movers are mostly budget and mid-market hosts:

Hostinger, 3 March 2026. KVM 4 went from \$9.99 to \$12.99 and has read \$12.99 on every night since, 133 readings through 30 August. The renewal price moved first, from \$24.99 to \$28.99 on 27 February, which is the pattern we keep seeing: the invoice rises before the storefront does.
Netcup, 4 June 2026. VPS 8000 G12 went from about \$42 to \$55 in USD terms, roughly 24%, and has held on all 86 readings since.
IONOS, 20 June 2026. The old VPS line was retired and replaced with the "+" range on yearly billing. Intro prices fell and renewals rose. VPS L+ has read \$6.00 renewing at \$21.00 on all 74 nights since.

Hetzner repriced its cloud range in mid-2026 and it is no longer the cheap default it was for a decade. Our own chart for it splits at 13 August 2026 for a data reason we document on the provider page, so treat the older part of that series as catalogue history rather than a clean nightly series.

The practical takeaway from all this stillness: a good price today will still be a good price when you get round to migrating. The risk is not that the market moves under you. The risk is your own renewal date.

What I would actually buy

Running a side project or a staging box, under \$10 a month. Contabo Cloud VPS 4 at \$5.06 for 8 GB, or OVHcloud VPS-1 at \$6.35 if you want a European provider whose price will not double. Both renew at what they advertise. Skip Time4VPS's \$5.04 here despite it topping the table, because the renewal doubles and 8 GB is not enough headroom to make the migration worth deferring.

Production WordPress or a small SaaS, 8 to 16 GB. Netcup VPS 1000 G12 at \$11.93 flat, or InterServer at \$12.00 flat if you want US datacentres and per-slice scaling. Hostinger KVM 4 gives you 16 GB for \$12.99, which is the best headroom per dollar in the set, but budget for \$28.99 when the two-year term ends. Worth comparing directly: Netcup against OVHcloud and Contabo against Hostinger.

You want an API, snapshots and managed databases. DigitalOcean or Vultr at around \$5 per GB. You are paying roughly 8x Contabo's rate for the ecosystem, and for a team shipping weekly that maths usually works.

You do not want to touch a server. Cloudways at \$99 for 8 GB. Expensive per gigabyte and correctly priced for what it removes from your week.

Avoid on the numbers. SiteGround's cloud tier at \$12.50 per GB, and any IONOS VPS bought without a calendar reminder for month twelve.

The full set of plans behind this analysis is browsable on our VPS hosting and cloud hosting pages, with the nightly price history attached to each provider profile. If you are still deciding whether you need any of this, when to upgrade from shared hosting is the earlier question.

Prices recorded 31 August 2026 from our nightly readings. EUR converted to USD. Monthly-equivalent figures; several budget plans require a 24-month commitment to hit the advertised rate.

Originally published at hostingsift.com.

ARM VPS Hosting in 2026: More Cores for Less Money

HostingSift — Fri, 28 Aug 2026 06:22:53 +0000

ARM processors are no longer just the chip in your phone. By 2026 they power a serious chunk of cloud infrastructure, and the most interesting part is that they have reached VPS plans at prices that make classic x86 servers look overpriced. Pick the right provider and you get more cores, lower power draw, and a bill that is dramatically smaller than what the American clouds charge.

This is a practical look. Real plans, real prices from our VPS hosting database (current as of June 2026), and an honest answer to when ARM is the better choice and when it still pays to stay on x86.

The short version

An ARM VPS is a virtual server running on an ARM chip (usually Ampere Altra) instead of a classic Intel or AMD one.
The best value in Europe comes from Netcup and Hetzner. Netcup literally gives you more cores for less money than its own x86 plans.
Netcup VPS 1000 ARM: 6 vCPU, 8 GB RAM, 256 GB NVMe for 7.77 EUR per month. The equivalent x86 plan costs 10.37 EUR.
Against the American clouds the gap is drastic. A 4 GB RAM plan on Hetzner ARM is around 3.79 EUR, while the same class at AWS Lightsail, Linode and Vultr runs between 20 and 24 USD.
ARM is excellent for web servers, containers, databases, CI/CD and Go or Node apps. Be more careful with legacy software that only ships x86 binaries.
ARM chips draw less power per unit of performance, so it is also the greener choice.

What ARM hosting actually is and why it is suddenly everywhere

For years servers were almost entirely x86 from Intel and AMD. ARM was for mobile devices because it sips power. Then Amazon launched Graviton, Ampere shipped Altra chips with dozens of cores, and cloud providers discovered something pleasant: ARM servers deliver comparable performance at lower power draw and a lower cost per core.

By 2026 that wave has reached the ordinary VPS market. Ampere Altra machines with up to 80 cores are being sliced into virtual plans you can rent for the price of a coffee. The software ecosystem has caught up too. Almost everything important now has an ARM64 build: the Linux distributions, Docker images, Node, Python, Go, PostgreSQL, MySQL, Nginx, Redis. That is exactly what was missing three years ago, and exactly why ARM is now a real option rather than an experiment.

ARM vs x86: the real price-per-resource comparison

The best way to feel the difference is to put ARM and x86 plans from the same provider side by side. Here is how it looks at Netcup, where the effect is clearest.

Plan	Architecture	vCPU	RAM	NVMe	Price/mo
VPS 1000 ARM G11	ARM (Ampere)	6 vCPU	8 GB	256 GB	7.77 EUR
VPS 1000 G12	x86	4 vCPU	8 GB	256 GB	10.37 EUR
VPS 2000 ARM G11	ARM (Ampere)	10 vCPU	16 GB	512 GB	13.41 EUR
VPS 2000 G12	x86	8 vCPU	16 GB	512 GB	19.25 EUR

Read that table again. At every tier the ARM plan has more cores, the same memory, the same disk space, and costs 25 to 30 percent less. This is not a marketing trick, it is a direct consequence of cheaper hardware. ARM cores are smaller and cheaper to manufacture, so the provider can pack more of them into a plan and still sell it for less.

Hetzner CAX: the pure Ampere line

Hetzner brands its ARM plans as CAX. They run on Ampere Altra and start genuinely low.

Plan	vCPU	RAM	NVMe	Price/mo
CAX11	2 vCPU	4 GB	40 GB	3.79 EUR
CAX21	4 vCPU	8 GB	80 GB	6.49 EUR
CAX31	8 vCPU	16 GB	160 GB	12.49 EUR
CAX41	16 vCPU	32 GB	320 GB	24.49 EUR

At Hetzner the small shared x86 plan (CX23) is a few cents cheaper than CAX11, so ARM does not win at the very bottom here. The real strength shows up when you need dedicated cores. Compare CAX31 with 8 ARM cores at 12.49 EUR against the dedicated x86 plan CCX23, which gives 4 cores for 24.49 EUR. For workloads that use every core, ARM simply delivers more compute per euro.

Netcup ARM G11: the most cores for the money

If you are chasing the maximum number of cores, Netcup ARM is hard to beat. VPS 8000 ARM gives 18 vCPU, 64 GB RAM and 2 TB NVMe for around 40 EUR per month. That is a resource density that would cost a four-figure bill at the American providers. It is also why Netcup is a favourite among people running databases, self-hosted apps and heavy container stacks.

How much cheaper it is than the American clouds

Here the difference stops being percentages and becomes a multiple. We take a 4 GB RAM class and put the European ARM plans next to the familiar American names we track in our database.

Provider	Plan	vCPU	RAM	Storage	Price/mo
Hetzner (ARM)	CAX11	2 vCPU	4 GB	40 GB NVMe	3.79 EUR
Vultr	Cloud Compute 4 GB	2 vCPU	4 GB	80 GB SSD	20.00 USD
Amazon Lightsail	4 GB / 2 vCPU	2 vCPU	4 GB	80 GB SSD	24.00 USD
Linode	Shared 4GB	2 vCPU	4 GB	80 GB SSD	24.00 USD
DigitalOcean	Basic 4 GB	2 vCPU	4 GB	80 GB NVMe	24.00 USD

Note: the ARM prices are in euros, the American ones in dollars. For reference, 24 USD is roughly 22 EUR at June 2026 rates, so the gap stays a multiple.

Same memory class, yet the bill on European ARM is five to six times smaller. It is fair to point out that part of the difference comes not only from the architecture but from the fact that Hetzner and Netcup are generally more aggressive on price than the hyperscalers. But the architecture helps. Among the American providers, AWS now offers its own ARM chips (Graviton), which are usually 10 to 20 percent cheaper than the x86 equivalent, confirming the same trend.

Before you fall in love with the lowest price, run your real scenario through our true cost calculator. The monthly price is one thing, but traffic, backups and add-on services change the picture.

What ARM is great for and what it is not

ARM is not a universal replacement. It shines on some workloads and creates headaches on others. Here is the honest breakdown.

Where ARM works brilliantly

Web servers and APIs. Nginx, Caddy, Node, Go, PHP, Python. All of these have mature ARM64 builds and run with no noticeable difference.
Containers. Docker and Kubernetes have supported ARM64 for a long time. Most popular images are multi-arch, so they pull the right version automatically.
Databases. PostgreSQL, MySQL, MariaDB and Redis run great on ARM, and the high core counts at Netcup help with parallel queries.
CI/CD and build machines. More cores per euro means faster builds, especially for Go and Rust projects that use every core.
Self-hosted apps. Nextcloud, Gitea, n8n, Vaultwarden and the like have official ARM images.

Where x86 is still worth it

Legacy software with x86-only binaries. Some closed corporate apps, old plugins or specific drivers have no ARM build. Check before you migrate.
Software with heavy x86 assembly optimizations. Rare cases, but they exist. Test performance, do not assume anything.
When your team has no time to test. If your stack has been x86 for years and everything works, the migration is a time cost you have to justify with real savings.

Energy efficiency and the green angle

ARM chips are designed to deliver maximum performance per watt. That started as a phone-battery advantage, but in the data center it turns into less power burned for the same work. Less power means a lower carbon footprint per request and lower operating costs, part of which comes back to you as a cheaper plan.

If sustainability is a factor in your choice, ARM hosting fits naturally. It is not a marketing sticker, it is a consequence of the architecture. Combine an ARM server with a provider that uses renewable energy and you get a serious cut in footprint without compromising performance.

How to migrate to ARM without pain

The transition is easier than most people expect, as long as you approach it methodically.

Inventory your stack. List every piece of software you run. For each one, check whether an ARM64 build exists. For mainstream things the answer is almost always yes.
Use multi-arch Docker images. If you are already on containers, most official images are multi-arch and the move is nearly seamless. You just run the stack on an ARM host.
Test on a cheap plan first. Grab a CAX11 for 3.79 EUR, deploy the app and run a load test. The cost of the experiment is symbolic.
Compare real performance. Do not look only at benchmarks. Measure response time and throughput of your own application under real load.
Migrate gradually. Move the non-critical services first. Once you are convinced, move production too.

If you are also considering self-hosting AI models on a budget server, read our guide to running local LLMs on a VPS under 5 dollars. Many of the same ARM considerations apply there.

Our recommendation

For most people who want the best value from an ARM VPS in 2026, the choice comes down to two providers.

Pick Netcup if you are chasing the maximum number of cores and disk space for your money. Their ARM plans literally beat their own x86 plans on value, and the higher tiers offer a resource density that is hard to match in Europe.

Pick Hetzner if you value a clean interface, hourly billing and a mature cloud ecosystem with snapshots, networks and load balancers. The CAX line is ideal for container and dedicated-core workloads.

And if you are tied to an American cloud because of a specific region or integration, check whether your provider offers ARM instances and compare them with the x86 equivalent. You will almost always save something. For the full picture, browse our cloud hosting and VPS categories.

Frequently asked questions

Is an ARM VPS slower than x86?

Not in any way you will notice on a typical web or application workload. A single ARM core on Ampere Altra is comparable to an x86 core for most tasks, and because you get more cores for the same money, total performance is often higher. Exceptions exist for very specific single-thread or x86-optimized workloads.

Will WordPress run on ARM hosting?

Yes, completely. PHP, MySQL or MariaDB, Nginx and Redis all have ARM builds. WordPress does not even know what architecture it runs on. This holds for most popular plugins too, because they are PHP rather than compiled binaries.

Can I run Docker on an ARM VPS?

Yes. Docker has supported ARM64 for years. Most official images are multi-arch and automatically pull the right version. If you build your own images, just make sure the base image has an ARM64 variant.

Why is European ARM so much cheaper than the American clouds?

Two reasons combine. First, providers like Hetzner and Netcup are generally more aggressive on price than the hyperscalers. Second, ARM hardware is cheaper per unit of performance, so they put more cores in a plan and still sell it for less.

Who is an ARM VPS not right for?

Teams that depend on closed software with x86-only binaries, or who have no resources to test the migration. If your stack is fully open and containerized, the benefits almost always win.

The takeaway for 2026 is simple. ARM is no longer an experiment but a mature, cheaper way to run almost any modern web application. Start with a plan for a few euros, run a real test, and see whether your bill has any reason to stay this high.

Originally published at hostingsift.com.

MCP Server Hosting: Where to Actually Deploy in 2026

HostingSift — Fri, 21 Aug 2026 15:42:03 +0000

Model Context Protocol went from "Anthropic curiosity" to "thing every AI tooling vendor implements" in roughly twelve months. If you build agentic apps in 2026, you almost certainly need to host an MCP server somewhere. The official docs cover the protocol. They do not cover the boring infrastructure question: where does this thing actually run, and what does it cost?

This guide answers that. We will look at the three deployment modes (stdio, HTTP, SSE), the security gotchas that bite teams in production, and the actual hosting price points for running MCP servers at scale. Real plans, real numbers from providers in our database.

What an MCP server is, in one paragraph

Model Context Protocol is an open standard from Anthropic that lets LLM applications connect to external tools and data sources through a unified interface. An MCP server exposes resources (files, database rows, API endpoints) and tools (functions the model can call) to any compatible client. Claude Desktop, Cursor, VS Code Copilot, and dozens of agent frameworks all speak MCP now. Build one server, plug into all of them.

The protocol itself is JSON-RPC 2.0 over a transport layer. That transport is where hosting decisions start mattering.

Three transport modes, three hosting profiles

1. Stdio (local only)

The server runs as a subprocess of the client. The client spawns your binary, talks to it over stdin/stdout, kills it on exit. Zero network surface. Zero hosting needed.

This is how every Claude Desktop config you have ever seen works. command: "node", args: ["./my-server.js"], done. Great for personal tools, code that runs against your local filesystem, anything you do not want exposed to the internet.

Hosting cost: zero. You are the host.

2. HTTP with Server-Sent Events (SSE)

The original networked transport. Server runs as a long-lived HTTP service. Clients connect, hold an SSE stream open, send requests over POST. This is the mode most public MCP servers use today.

Hosting requirements: a process that stays running, a public URL with TLS, and a host that does not kill long-lived connections. That last one matters more than people realize. Serverless platforms with hard timeouts (Vercel Functions, Cloudflare Workers default tier) will close the SSE stream after 10-60 seconds. Game over.

3. Streamable HTTP (the 2025 spec update)

Anthropic merged SSE and POST into one bidirectional endpoint. Stateless mode is possible. Each request is a self-contained exchange. This unlocks serverless and edge deployments because you no longer need a persistent connection.

Stateless streamable HTTP is the mode you want if your server does not need session memory. Stateful mode still requires a sticky backend.

Picking the right host

The decision tree:

Stateless streamable HTTP, low traffic: serverless or PaaS. Cheapest.
Stateful SSE, persistent connections: VPS or container platform.
High traffic, autoscaling: managed container service or Kubernetes.
Internal-only, behind VPN: any VPS with a private network.

Most teams overestimate which bucket they fall into. If your MCP server fronts a small API and gets a few hundred requests per day, you do not need Kubernetes. A 4 EUR VPS is fine.

Self-hosted on a VPS: the realistic baseline

This is what most production MCP servers actually run on. A small VPS, Node or Python process behind a reverse proxy, systemd keeping it alive. Total cost: under 10 EUR per month.

Provider	Plan	vCPU / RAM	Storage	Price
Hetzner	CX23	2 / 4 GB	40 GB NVMe	3.49 EUR/mo
Hetzner	CAX11 (ARM)	2 / 4 GB	40 GB NVMe	3.79 EUR/mo
Netcup	VPS 500 G12	2 / 4 GB	128 GB NVMe	4.87 EUR/mo
Contabo	Cloud VPS 10	4 / 8 GB	75 GB NVMe	3.60 EUR/mo
DigitalOcean	Basic Regular 1 GB	1 / 1 GB	25 GB SSD	$6/mo
Vultr	Regular Cloud Compute	1 / 1 GB	25 GB SSD	$6/mo
Linode	Shared Nanode	1 / 1 GB	25 GB SSD	$5/mo

The Hetzner CX23 at 3.49 EUR has shocked a lot of engineers in 2026. Two vCPUs and 4 GB RAM for the price of a coffee. It handles MCP servers with hundreds of concurrent SSE connections without breaking a sweat.

For pure value, Contabo Cloud VPS 10 at 3.60 EUR gives you 4 vCPU and 8 GB RAM, but the I/O is slower and latency varies. Fine for a hobby MCP server. Not what you want for production.

If you are running multiple MCP servers and need elbow room, the Hetzner CCX13 dedicated AMD instance at 12.49 EUR with 2 dedicated vCPUs and 8 GB RAM is the sweet spot most teams converge on.

The setup, briefly

Provision the VPS. Install Node or Python. Clone your MCP server repo. Wrap the process in systemd (or PM2 if you prefer). Put Caddy or nginx in front for TLS. Open port 443. Done.

Anthropic publishes a TypeScript SDK and a Python SDK. Both have starter templates. Most teams have their first MCP server live in under an hour.

PaaS deployment: less work, slightly more money

If you do not want to think about systemd or TLS certs, Railway and Render handle the plumbing.

Railway charges per resource used. A small MCP server with 512 MB RAM and minimal CPU lands around $5 to $8 per month including bandwidth. You push from GitHub, Railway builds and deploys. SSE works out of the box because Railway runs your container long-lived.

Render's Web Service plans start at $7 per month for 512 MB RAM, $25 for 2 GB. Render also handles SSE and WebSockets correctly. Their free tier spins down after inactivity, which kills MCP servers, so do not use it for anything serious.

The tradeoff is honest: PaaS costs roughly 2x what a Hetzner VPS costs for equivalent resources, and you trade that money for zero ops work. Worth it for small teams without an ops person.

For deeper PaaS analysis, see our PaaS hosting comparison.

Serverless: cheap and fast, with caveats

Streamable HTTP in stateless mode opens the door to truly serverless MCP servers. Cloudflare Workers, AWS Lambda, Vercel Functions can all host an MCP endpoint as long as each request is self-contained.

Cloudflare Workers is probably the best fit. Global edge, zero cold starts under typical load, $5 per month for 10 million requests on the paid tier. Their nodejs_compat flag handles the Anthropic SDK reasonably well.

Watch out for these limits:

Request timeout: Workers is 30 seconds CPU time, Lambda is 15 minutes max, Vercel Hobby is 10 seconds (yes, 10).
Response size: Workers caps at 100 MB streamed, Lambda at 6 MB synchronous.
Cold starts: relevant if your MCP server hits cold instances often. Workers wins here.

If your MCP server wraps a slow external API and individual tool calls might take 45 seconds, serverless is wrong. Use a VPS.

If your MCP server is a thin wrapper around a fast database query, serverless is perfect and you might never spend more than a few dollars per month.

The security part nobody likes talking about

An MCP server is a remote code execution surface for whoever talks to it. The LLM client calls tools on your server. Those tools execute code. If you expose that endpoint to the public internet without auth, you are running an open execution endpoint.

Here is what teams keep getting wrong:

1. No authentication on the MCP endpoint

The MCP spec supports OAuth 2.1 for HTTP transports. Use it. Anthropic added OAuth flows to the spec in 2025 specifically because too many public MCP servers shipped without auth.

If OAuth is too much for your use case, at minimum require a bearer token in the Authorization header and validate it on every request. Hardcoded API keys in env vars work fine for B2B MCP servers used by a single client team.

2. Tools that take filesystem paths

An MCP tool called read_file(path) that does no path validation is a path traversal exploit waiting to happen. The LLM will eventually try ../../../etc/passwd because the user asked it to debug something. Validate. Sandbox. Use chroot or container isolation for anything filesystem-related.

3. Database tools with no row-level filtering

If your MCP server exposes a query_users() tool, the LLM client speaks for whoever invoked it. Pass user identity through the protocol context and apply row-level security at the database. Otherwise tenant A can ask their AI for tenant B's data through your MCP server, and your AI will happily oblige.

4. Rate limiting

LLMs in agent loops can hammer an endpoint. A buggy agent we saw last quarter called the same MCP tool 4,000 times in two minutes before timing out. Without rate limiting that becomes your AWS bill. Caddy and Cloudflare both do this cheaply.

Real-world architecture: MCP server in front of a SaaS API

The most common production pattern in 2026 looks like this:

Your existing SaaS has a REST API.
You write an MCP server that wraps the REST API in tool definitions.
The MCP server runs on a small VPS or Railway service.
OAuth flow issues per-customer tokens.
Claude/Cursor/your-agent-of-choice connects to the MCP server using those tokens.

This unlocks AI integration without forcing your customers to integrate with twenty different agent frameworks. You build one MCP server. Everything else just works.

For a B2B SaaS doing 50,000 tool calls per day, this entire setup runs comfortably on a 6.49 EUR Hetzner CPX22 with Caddy fronting the Node process. Total monthly bill: under 10 EUR including bandwidth.

Where MCP server hosting is going

Two trends to watch in 2026:

MCP marketplaces. Anthropic, Glama, and Smithery are building registries where third parties publish hosted MCP servers. You will not always host your own. You will sometimes use a hosted MCP server the way you use a third-party API today. Pricing models there are still shaking out, mostly per-call or per-seat.

MCP-native hosting platforms. A handful of providers are building dedicated MCP hosting products: deploy your server with one command, get OAuth and rate limiting included, pay per request. Expect this category to consolidate quickly. By 2027 we will probably have two or three dominant players the same way Vercel won Next.js hosting.

For now, a VPS plus a half-day of setup gets you a production MCP server cheaper than any managed alternative.

The 30-second recommendation

Building your first MCP server for testing? Stdio mode, local machine. No hosting.

Shipping an MCP server to a customer or to the public? Hetzner CX23 at 3.49 EUR plus Caddy plus systemd. You will spend an hour setting up. The thing will run for years.

Already on a PaaS for your main app? Add the MCP server to the same project on Railway or Render. Your bill goes up by maybe $5 per month.

Want zero ops and very low traffic? Stateless streamable HTTP on Cloudflare Workers. Free tier handles a surprising amount.

The hosting decision matters less than the security one. Auth your endpoint, validate your tool inputs, rate-limit your server. Then ship.

Originally published at hostingsift.com

Self-Hosted LLM on a $5 VPS in 2026: What Actually Works

HostingSift — Wed, 12 Aug 2026 05:05:12 +0000

"Run your own ChatGPT for five bucks a month" sounds like cheap clickbait. And mostly it is. But the gap between clickbait and reality has narrowed a lot in 2026. Quantized 3B and 7B models have become genuinely useful. VPS providers now pack 8 GB of RAM into plans under $6. If you pick carefully, you can run a respectable local model on a budget server.

This article is about what actually works, what falls over, and which provider from our hosting comparison gives you the most compute per dollar for AI workloads.

The short version

You will not run GPT-4-class models on a $5 VPS. Stop expecting to.
You can run Llama 3.2-3B, Qwen 2.5-7B, or Mistral-7B in 4-bit quantization if you have at least 8 GB of RAM.
CPU inference is slow (5 to 15 tokens per second) but usable for personal automation, chatbots with low traffic, or embedding generation.
The providers that matter for this use case: Contabo and Netcup, both German-speaking and both useful for EU data residency. Hetzner has pulled its entire budget line from sale, so its entry point here is now €35.49 rather than €8.49.
Avoid US hyperscaler $5 plans (DO, Vultr, Linode) for LLM work. Same price, one quarter of the RAM.

Why self-host an LLM at all?

Three reasons keep coming up in our research:

Privacy. 44% of organizations cite data privacy as the top barrier to adopting hosted LLM APIs. Self-hosting means your prompts, documents, and customer data never leave your box. For law firms, clinics, and anyone building internal knowledge bases, this is non-negotiable.

Cost at volume. Hosted API costs add up fast once you run batch jobs, background summarization, or embedding pipelines. The rough break-even with a $5 VPS sits around two million tokens per day for small models. Below that, APIs are cheaper. Above that, self-hosting starts to win.

Learning and control. You get to pick the model, tune the system prompt at the weight level (via LoRA adapters), and run without rate limits. Worth it for developers.

What "self-hosted LLM" actually needs

Before we compare VPS plans, a quick hardware reality check. On CPU-only servers (which every budget VPS is), the bottleneck is RAM bandwidth, not CPU speed. Model weights must fit in RAM, and every token generation pass reads the entire weight file. So the two numbers that matter are:

RAM size. Determines which model you can load at all.
RAM bandwidth. Determines how many tokens per second you get.

Here is roughly what each tier can do in 4-bit quantization (GGUF format, llama.cpp inference):

Update (12 August 2026) — corrections. A data audit found two errors in the earlier version of this article, and we would rather say so plainly than quietly swap the numbers.

Hetzner's entire budget line is no longer sold. The CX23/33/43/53 and CAX11/21/31/41 plans are marked "not available" on Hetzner's own site, in every location. Their listed prices are still accurate, which is exactly why our checks missed it — we were tracking price, not stock. The cheapest Hetzner plan you can actually buy with 8 GB of RAM is now the CPX32 at €35.49, roughly four times the €8.49 CX33 this article originally recommended. That single fact changes the shape of this comparison, so the Hetzner section below has been rewritten rather than repriced.

Our Contabo prices were wrong, and the catalogue was stale. The Contabo plans quoted earlier — Cloud VPS 10 at €3.60 and Cloud VPS 20 at €5.60 — no longer exist. Contabo replaced that line with Cloud VPS 4 through 18 (the number is the vCPU count) and our scraper had been serving cached figures rather than reading the live site, understating some prices by up to 38%. Everything below is now read from Contabo's live pricing page.

Netcup's VPS 1000 ARM G11 did move honestly, from €6.26 to €7.77. The full change history for all three is on our Hetzner, Netcup and Contabo price history pages.

RAM	Largest usable model	Realistic tokens/sec (CPU)	Good for
2 GB	Qwen 2.5-0.5B, Llama 3.2-1B	20-40 tok/s	Embeddings, simple classification
4 GB	Llama 3.2-3B, Phi-3.5 Mini	8-15 tok/s	Personal chatbots, summarization
8 GB	Qwen 2.5-7B, Mistral-7B, Llama 3.1-8B	4-8 tok/s	Production-adjacent use, RAG
16 GB	Mixtral 8x7B (barely), Qwen 2.5-14B	2-4 tok/s	More complex reasoning

Below 8 GB you are limited to small models. Above 8 GB you unlock the "actually useful" tier. This matters enormously when picking a VPS.

The $3 to $6 VPS plans that can run real LLMs

Pulled directly from our database, filtered to plans where the RAM is at least 8 GB (the practical floor for running a 7B model in 4-bit quantization) and that the provider will actually sell you today. The first price is the 24-month rate; the figure in brackets is what you pay month-to-month with no commitment.

Provider	Plan	Price / mo	RAM	vCPU	Storage	Bandwidth
Contabo	Cloud VPS 4	€4.40 (€5.50)	8 GB	4 vCPU	100 GB SSD	Unlimited
Contabo	Cloud VPS 6	€6.00 (€7.50)	12 GB	6 vCPU	200 GB SSD	Unlimited
Netcup	VPS 1000 ARM G11	€7.77	8 GB	6 vCPU (ARM)	256 GB NVMe	Unlimited
Contabo	Cloud VPS Plus 4	€10.80 (€13.50)	8 GB	4 vCPU (AMD EPYC)	150 GB NVMe	Unlimited
Hetzner	CPX32	€35.49	8 GB	4 vCPU	160 GB NVMe	20 TB

Compare that to the "famous" $5 cloud plans:

Provider	Plan	Price / mo	RAM	vCPU
DigitalOcean	Basic Regular	$4.00	512 MiB	1 vCPU
Vultr	CC Regular	$2.50	512 MB	1 vCPU
Linode	Shared Nanode	$5.00	1 GB	1 vCPU

That 8x RAM difference at the same price point is the whole reason European providers win this category. DO, Vultr and Linode are excellent for web apps and small services. They are not designed for the RAM-heavy workload an LLM needs.

Provider deep dive

Contabo: the price-per-GB winner

Contabo Cloud VPS 4 gives you 8 GB RAM, 4 vCPU and 100 GB SSD for €4.40 a month on a two-year term, or €5.50 with no commitment. Nothing else in this comparison matches that. The catch is real: Contabo is known for inconsistent CPU steal on noisy neighbours, and network latency can be variable. For LLM inference, which is RAM-bound rather than network-bound, that tradeoff is usually acceptable.

Go up one tier to Cloud VPS 6 at €6.00 (€7.50 monthly) for 12 GB RAM and 6 vCPU. This is the sweet spot for running Qwen 2.5-14B in 4-bit while still having headroom for a web server and a small vector database on the same machine.

One note on storage, since it changed with the new line: the standard Cloud VPS tiers ship SSD, not NVMe. If disk speed matters to you — loading an 8 GB model off disk on every restart, for instance — Cloud VPS Plus 4 at €10.80 keeps the same 8 GB of RAM but moves you to 150 GB of NVMe on AMD EPYC cores.

Hetzner: no longer competing at this price

Hetzner used to be the obvious quality pick here, and this article said so. That is no longer true, for a reason that has nothing to do with price: the whole cost-optimised line — CX23 through CX53 and CAX11 through CAX41 — is marked "not available" on Hetzner's site, in every location. The prices are still published, which is what fooled our tracker for a month, but you cannot buy the machines.

What remains purchasable with 8 GB of RAM starts at the CPX32, €35.49 a month. It is a genuinely good server — AMD EPYC cores, 160 GB NVMe, 20 TB of bandwidth, datacentres in Germany, Finland and Virginia, and a control panel that is minimal in the good way. It is simply in a different price bracket, four times the CX33 it replaces, and it is hard to justify for a hobby inference box when Contabo sells 8 GB for €4.40.

The loss worth mourning is the ARM line. The CAX21's Ampere Altra cores benchmarked roughly 15 to 25 percent faster than the x86 CX33 on llama.cpp thanks to higher sustained memory bandwidth, which made it the best tokens-per-euro option in this whole comparison. If Hetzner brings that line back, it goes straight back into this table — our Hetzner price history page tracks it nightly.

Netcup: the quiet competitor

Less known outside the German-speaking market. The VPS 1000 ARM G11 at €7.77 gives you 8 GB RAM, 6 vCPU, and 256 GB of NVMe, which is the largest disk in this comparison. Useful if you want to store multiple models and switch between them without re-downloading 4 to 8 GB each time.

What you will actually run on 8 GB

Here is the honest menu for an 8 GB VPS with Ollama or llama.cpp:

Qwen 2.5-7B-Instruct (Q4_K_M). Best general-purpose model in this size. Strong reasoning, multi-language, clean code.
Llama 3.1-8B-Instruct (Q4_K_M). Ubiquitous, well-supported, safe default. Slightly weaker than Qwen on code.
Mistral-7B-Instruct-v0.3 (Q5_K_M). Older but predictable. Good for summarization.
Phi-3.5-Mini (Q6_K). Smaller (3.8B), fits in 4 GB of RAM, quick for chat.
nomic-embed-text or bge-small-en. Embedding models for RAG pipelines. Run these alongside the main model.

What you will not run well: anything 14B+, models with vision capabilities (qwen-vl, llava), or anything demanding low-latency streaming to many users.

Practical setup in 15 minutes

Rough sketch so you know what you are signing up for. This assumes Ubuntu 22.04 or 24.04 on a 8 GB VPS.

# 1. Install Ollama (handles download, quantization, serving)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Pull a model
ollama pull qwen2.5:7b-instruct-q4_K_M

# 3. Test
ollama run qwen2.5:7b-instruct-q4_K_M "Summarize the French Revolution in two paragraphs."

# 4. Expose the API (careful with firewall rules)
# Ollama serves on localhost:11434 by default. Reverse-proxy with Caddy or Nginx.

Add Open WebUI if you want a ChatGPT-like browser interface. Add llama-swap if you want to load different models on demand without restarting.

When NOT to self-host

A $5 VPS gives you about 5 to 8 tokens per second on a 7B model. That is fine for one user typing in a chat. It is not fine for:

Real-time voice assistants. Latency will be embarrassing.
Multi-user chat services. Four concurrent users will queue and feel broken.
Anything that needs tool use, function calling at scale, or long-context (>8K tokens).
Production RAG over millions of documents with tight latency SLAs.

For those workloads, you want a GPU instance. That immediately pushes you above $100/month with Vast.ai, RunPod, or a dedicated server with a consumer GPU. At that point, OpenAI API or Anthropic API is often cheaper up to surprisingly high volumes.

Quick comparison: which $5 to $7 VPS wins?

Use case	Best pick	Why
Lowest price with 8 GB RAM	Contabo Cloud VPS 4	€4.40 for 8 GB is unmatched
Best tokens per second per euro	Netcup VPS 1000 ARM G11	ARM memory bandwidth, now that Hetzner's CAX line is unavailable
Largest model storage	Netcup VPS 1000 ARM G11	256 GB NVMe stores a dozen models easily
Fast disk for model loading	Contabo Cloud VPS Plus 4	150 GB NVMe on EPYC; standard Cloud VPS is SSD
Running LLM + web app on one box	Contabo Cloud VPS 6	12 GB RAM leaves room for Postgres and nginx
Reliability regardless of price	Hetzner CPX32	The cheapest 8 GB Hetzner you can still buy, at €35.49

You can also compare them side by side on Contabo vs Hetzner or review the full cloud VPS category.

What changes this year

Two developments worth tracking in 2026:

Smaller models keep getting smarter. Phi-3.5 Mini already outperforms last year's 13B models on some benchmarks. Expect 2B and 3B models to be genuinely production-useful by Q4 2026. That makes the 2 GB RAM tier (under $2) a legitimate option.

ARM inference is closing the gap. Apple showed what M-series can do. Ampere Altra and AWS Graviton are bringing similar memory bandwidth advantages to $5 VPS plans. If you have not tried ARM yet, this is the year.

The verdict

If you want to learn, build a personal assistant, run background summarization, or stand up a private chatbot for a small team, a €5 to €8 VPS with 8 GB of RAM is genuinely enough in 2026. Pick Contabo for raw price, Netcup for ARM throughput and storage. Hetzner is still the reliability benchmark, but until its cost-optimised line comes back, entry is €35.49 rather than €8.49. Avoid the US hyperscaler budget tiers; they are optimised for a different use case.

If you want to serve real users at real volume, stop pretending a shared VPS is the answer. Use an API, or skip straight to a GPU host.

The Raw Power of Svelte 5 Runes: 70 Components, 25 KB, Full Reactivity

HostingSift — Wed, 25 Feb 2026 13:14:30 +0000

Svelte 5 Runes in Production: What We Learned Building 70+ Components

When Svelte 5 shipped runes, the community split in two. One side said "you're just copying React." The other saw the future of reactivity. We just started writing code. 70+ components later, powering HostingSift (a hosting comparison platform), here's what we actually know.

What runes are and why you should care

Runes are compiler instructions. They look like functions ($state(), $derived(), $effect()), but they're not. Svelte transforms them at build time, not at runtime. That's the key difference from React hooks, Vue composables, and everything else out there.

In Svelte 4, reactivity was implicit. Write let count = 0 and the compiler decides when to update the DOM. It worked, but it had traps. $: blocks got confusing with complex logic, and the line between "reactive" and "just a variable" was blurry.

Runes fix that with explicit signals:

<script lang="ts">
  let hostings = $state<Hosting[]>([])
  let loading = $state(true)
  let error = $state<string | null>(null)
  let currentSort = $state('rating')

  const totalPages = $derived(Math.ceil(total / limit))

  $effect(() => {
    if (currentQueryString !== undefined) {
      fetchHostings()
    }
  })
</script>

You read it and know exactly what's reactive. No magic. No guessing.

The reactivity model: what actually happens under the hood

Here's the thing most articles skip. Svelte 5's reactivity is signal-based, but the compiler does the dependency tracking for you. You never call createSignal() or wrap things in ref(). You write normal JavaScript and the compiler figures out the reactive graph.

When you write:

let loading = $state(true)

The compiler turns it into something like:

let loading = $.source(true)

Every read of loading in the template or in a $derived/$effect block registers a dependency. Every write triggers updates to anything that depends on it. No manual dependency arrays. No stale closure bugs.

This is fundamentally different from React's model. In React, useEffect re-runs based on a dependency array you maintain. Forget a dependency, get a stale value. Add too many, get infinite loops. Svelte tracks dependencies automatically because it controls the compiler. The reactive graph is built at compile time, not runtime.

Compared to Vue's ref() / reactive(), you also skip the .value ceremony. In Vue you write count.value++. In Svelte you write count++. The compiler knows it's reactive and generates the right code.

How we built a reactive filter system with runes

This is where runes really clicked for us. Our hosting comparison page has multiple filter dimensions: hosting type, technology stack, price range, search, sort order, pagination. Each filter lives in its own nanostore atom, and they all feed into a computed API query string.

Here's the store layer (plain nanostores, framework-agnostic):

// stores/filters.ts
import { atom, computed } from 'nanostores'

export const $type = atom<string | null>(null)
export const $tech = atom<string[]>([])
export const $minPrice = atom<number>(0)
export const $maxPrice = atom<number>(1000)
export const $sort = atom<string>('price-asc')
export const $page = atom<number>(1)
export const $search = atom<string>('')

// This recomputes whenever ANY filter changes
export const $apiQueryString = computed(
  [$type, $tech, $minPrice, $maxPrice, $sort, $page, $search],
  (type, tech, minPrice, maxPrice, sort, page, search) => {
    const params = new URLSearchParams()
    if (type) params.set('type', type)
    if (tech.length) params.set('tech', tech.join(','))
    // ...
    return params.toString()
  }
)

Seven independent atoms feeding into one computed query string. When you change any filter, $apiQueryString recomputes and the list refetches. That's the reactive graph in action.

Now here's the interesting part: bridging this into Svelte 5 components.

The bridge pattern we use everywhere

Nanostores don't know about runes. So we bridge them with a pattern that shows up in almost every component:

<script lang="ts">
  import { $type as typeStore, setType } from '../../stores/filters'

  let activeType = $state<string | null>(typeStore.get())

  $effect(() => {
    return typeStore.subscribe(val => { activeType = val })
  })
</script>

Three lines: initial value from the store, subscribe in an effect, cleanup returned automatically. Every filter component does this. TypeTabs, TechFilter, PriceRangeSlider, ActiveFilters all follow the same pattern.

For components that track multiple stores, we batch the subscriptions:

$effect(() => {
  const unsubs = [
    typeStore.subscribe(val => { currentType = val }),
    techStore.subscribe(val => { currentTech = val }),
    minPriceStore.subscribe(val => { currentMinPrice = val }),
    maxPriceStore.subscribe(val => { currentMaxPrice = val }),
    priceMaxStore.subscribe(val => { ceiling = val }),
    priceFloorStore.subscribe(val => { floor = val }),
  ]
  return () => unsubs.forEach(unsub => unsub())
})

One effect, six subscriptions, one cleanup function. The effect runs once on mount, subscribes to everything, and cleans up all listeners when the component is destroyed. In React you'd need useEffect with a dependency array (probably wrong on the first try) or multiple useEffect calls. Here it's flat and obvious.

$derived for computed filter state

The real power shows when you start deriving values. Our ActiveFilters component needs to know if any filter is active:

const hasFilters = $derived(
  currentType !== null ||
  currentTech.length > 0 ||
  currentMinPrice > floor ||
  currentMaxPrice < ceiling
)

No useMemo. No cache key. Just an expression that re-evaluates when any of its dependencies change. Svelte tracks which $state variables you read inside $derived and only recalculates when those specific values change.

The TechFilter component uses $derived for show/hide logic:

const visibleOptions = $derived(
  showAll ? techOptions : techOptions.slice(0, VISIBLE_COUNT)
)
const hiddenCount = $derived(
  Math.max(0, techOptions.length - VISIBLE_COUNT)
)

When showAll flips or techOptions changes (after the API responds), both derived values update and the template re-renders. You don't think about it. It just works.

The price slider: reactive all the way down

Our dual-range price slider is the most reactive component we have. It juggles local drag state, store values, computed percentages, and dynamically generated pip labels:

let localMin = $state(minPriceStore.get())
let localMax = $state(maxPriceStore.get())
let ceiling = $state(priceMaxStore.get())
let isDragging = $state(false)

// Sync from store, but not while dragging
$effect(() => {
  const unsubMin = minPriceStore.subscribe(val => {
    if (!isDragging) localMin = val
  })
  const unsubMax = maxPriceStore.subscribe(val => {
    if (!isDragging) localMax = val
  })
  // ...
  return () => { unsubMin(); unsubMax(); /* ... */ }
})

// These recompute on every drag frame
const range = $derived(ceiling - floor)
const minPercent = $derived(range > 0 ? ((localMin - floor) / range) * 100 : 0)
const maxPercent = $derived(range > 0 ? ((localMax - floor) / range) * 100 : 100)

As the user drags, localMin/localMax update, which triggers minPercent/maxPercent to recompute, which moves the slider fill in the template. When they release, we commit to the store, which triggers the API fetch. The isDragging guard prevents the store subscription from fighting with the local drag state.

In React you'd model this with useState + useRef + useCallback + useEffect with carefully managed dependency arrays. Here it's just assignments and derived values. The compiler handles the rest.

The pip labels are a $derived.by() because the logic needs intermediate variables:

const pips = $derived.by(() => {
  if (range <= 0) return [`$${floor}`]
  const rough = range / 5
  const mag = Math.pow(10, Math.floor(Math.log10(rough || 1)))
  const norm = rough / mag
  const step = norm <= 1 ? mag : norm <= 2 ? 2 * mag : 5 * mag
  const labels: string[] = [`$${floor}`]
  for (let v = Math.ceil(floor / step) * step; v < ceiling; v += step) {
    labels.push(`$${v}`)
  }
  return labels
})

$derived() is for single expressions. $derived.by() is for when you need if, for, or temporary variables. Both are reactive the same way.

$effect: the cleanup story

The killer feature of $effect isn't the effect itself. It's the cleanup. You return a function and Svelte calls it when dependencies change or the component unmounts. No onDestroy import, no separate cleanup lifecycle.

Click outside handler with automatic cleanup:

$effect(() => {
  if (searchOpen) {
    document.addEventListener('click', handleClickOutside)
    return () => document.removeEventListener('click', handleClickOutside)
  }
})

The listener only exists while the dropdown is open. Close it, listener gone. Unmount the component, listener gone. You can't forget.

Body scroll lock for a mobile bottom sheet:

let isOpen = $state(false)

function open() {
  isOpen = true
  document.body.style.overflow = 'hidden'
}

function close() {
  isOpen = false
  document.body.style.overflow = ''
}

No effect needed here because the state change is synchronous and user-driven. That's another thing runes teach you: not everything needs to be reactive. Sometimes a plain function is better.

The simplicity argument: less code, fewer bugs

Let's be blunt. Every framework claims to be simple. But simplicity isn't about marketing copy. It's about how much code you write for the same result, and how many places that code can go wrong.

Here's a toggle button. React:

const [isOpen, setIsOpen] = useState(false)

Vue:

const isOpen = ref(false)

Svelte:

let isOpen = $state(false)

All three are one-liners. Fair enough. Now let's look at something real: a component that reads from an external store, derives a computed value, and cleans up on unmount.

React version of our TypeTabs filter:

function TypeTabs() {
  const [activeType, setActiveType] = useState(typeStore.get())

  useEffect(() => {
    const unsub = typeStore.subscribe(val => setActiveType(val))
    return unsub
  }, [])

  const handleClick = useCallback((value) => {
    setType(value)
  }, [])

  return (
    <div className="flex flex-wrap gap-2">
      {TYPES.map(t => (
        <button
          key={t.value}
          className={`chip ${activeType === t.value ? 'active' : ''}`}
          onClick={() => handleClick(t.value)}
        >
          {t.label}
        </button>
      ))}
    </div>
  )
}

Svelte version. The actual code we ship:

<script lang="ts">
  import { $type as typeStore, setType } from '../../stores/filters'

  let activeType = $state<string | null>(typeStore.get())

  $effect(() => {
    return typeStore.subscribe(val => { activeType = val })
  })
</script>

<div class="flex flex-wrap gap-2">
  {#each TYPES as t}
    <button
      class="chip {activeType === t.value ? 'active' : ''}"
      onclick={() => setType(t.value)}
    >
      {t.label}
    </button>
  {/each}
</div>

Count the concepts. React: useState, useEffect, useCallback, dependency array, JSX return statement, className instead of class, key prop. Svelte: $state, $effect, template. That's it.

The React version has more ways to break. Forget the dependency array, you get stale state. Skip useCallback, you get unnecessary re-renders (or your linter screams at you). The Svelte version has one moving part: the store subscription with automatic cleanup.

Now look at our ActiveFilters component. It subscribes to 6 stores and derives a boolean:

let currentType = $state(typeStore.get())
let currentTech = $state(techStore.get())
let currentMinPrice = $state(minPriceStore.get())
let currentMaxPrice = $state(maxPriceStore.get())
let ceiling = $state(priceMaxStore.get())
let floor = $state(priceFloorStore.get())

$effect(() => {
  const unsubs = [
    typeStore.subscribe(val => { currentType = val }),
    techStore.subscribe(val => { currentTech = val }),
    minPriceStore.subscribe(val => { currentMinPrice = val }),
    maxPriceStore.subscribe(val => { currentMaxPrice = val }),
    priceMaxStore.subscribe(val => { ceiling = val }),
    priceFloorStore.subscribe(val => { floor = val }),
  ]
  return () => unsubs.forEach(unsub => unsub())
})

const hasFilters = $derived(
  currentType !== null ||
  currentTech.length > 0 ||
  currentMinPrice > floor ||
  currentMaxPrice < ceiling
)

In React, this would be six useState calls, a useEffect with an empty dependency array, and a useMemo with six dependencies (that you'd probably get wrong on the first try). Or you'd pull in Zustand or Jotai and add another abstraction layer.

In Svelte, it's assignments and one effect. $derived doesn't need you to list dependencies. The compiler reads the expression and tracks them automatically.

This scales. Our most complex component (HostingList) has 12 $state declarations, 4 $derived values, 5 $effect blocks, and handles search, sort, filters, pagination, and compare selection. It's 286 lines including the template. The equivalent React component would easily be 400+, and most of that extra code would be dependency arrays, memoization, and state setter functions.

The point isn't that React is bad. It's that Svelte's compiler does work that React pushes onto the developer. Less manual bookkeeping means fewer places to mess up.

$props: TypeScript-first component contracts

interface Props {
  items: CompareItem[]
  max?: number
  onRemove: (id: string) => void
  onClear: () => void
  onCompare: () => void
}

let { items, max = 4, onRemove, onClear, onCompare }: Props = $props()

Instead of export let items and hoping the parent passes the right type. TypeScript catches mistakes at compile time. Default values work with standard destructuring. Callbacks are just props, same as React.

Bundle size: the actual numbers

Svelte 5 compiles runes to vanilla JS at build time. There's no 40+ KB runtime (React) or 30+ KB runtime (Vue) shipped to the browser. Svelte's runtime is under 5 KB gzipped and tree-shakes aggressively.

In our case: 70+ Svelte components including a quiz wizard, dual-range price slider, filter system, compare bar, review form, and a full admin panel. Client JS stays under 25 KB per page (gzipped, including routing). React's runtime alone is bigger than that.

Runes add zero overhead. $state(0) compiles to:

let rating = $.source(0)

$derived(items.length >= 2) becomes:

let canCompare = $.derived(() => $.get(items).length >= 2)

The compiler knows exactly which values are reactive and generates only the code it needs. No virtual DOM diffing. No runtime dependency tracking. Just surgical DOM updates.

What surprised us

Granular updates without effort. When hostings = newArray runs, Svelte doesn't re-render the whole list. It diffs the keyed {#each} block and only touches changed DOM nodes. We never had to think about React.memo or shouldComponentUpdate.

Conditional effects actually work. $effect + if + return cleanup gives you fine-grained control in 5 lines. The click-outside handler above would be a custom hook in React (15+ lines, reusable but noisy).

TypeScript just works. $state<Hosting[]>([]) does what you expect. No wrapper types, no utility generics, no Ref<T> vs T.

Derived chains are fast. floor changes, range recomputes, minPercent recomputes, pips recomputes, DOM updates. Four levels of derived state and it's instant because each step only runs if its inputs changed.

What bites

The nanostores bridge. Four lines per store isn't terrible, but it's ceremony. We'll probably write a useNanostore() utility at some point. For now the pattern is consistent and bug-free.

$effect grabs everything it reads. If you read currentQueryString inside an effect, the effect re-runs when it changes. This is correct behavior, but you need to be careful not to trigger infinite loops (effect writes to state that the effect reads).

Migrating from Svelte 4. Not trivial. $: blocks need to be split into $derived and $effect. export let becomes $props(). The good news: npx sv migrate svelte-5 handles 90% of cases.

Quick reference

Rune	Use case	Example
`$state()`	Mutable value	`let loading = $state(true)`
`$derived()`	Computed from state	`const total = $derived(items.length)`
`$derived.by()`	Complex computed with if/for	`$derived.by(() => { ... })`
`$effect()`	Side effects, subscriptions	Fetch, event listeners, store sync
`$props()`	Component inputs	`let { name } = $props()`
`$bindable()`	Two-way binding prop	`let { value = $bindable() } = $props()`

Bottom line

Runes make reactivity explicit. You know what's state, what's computed, what's a side effect. The compiler generates minimal code. TypeScript works without hacks. The reactive graph is built once at compile time and runs with near-zero overhead.

We run 70+ components in production at HostingSift with Astro SSR, nanostores for cross-island state, and Svelte 5 runes for local reactivity. A full filter system with type tabs, technology chips, a dual-range price slider, active filter pills, search with autocomplete, and sort dropdown. All reactive, all coordinated through a single computed query string, all under 25 KB shipped to the browser.

If you're starting a new project and the React/Vue/Svelte decision is eating your time, just try runes. They're different enough to deserve a real look.

Why we chose Astro over SvelteKit for our hosting comparison platform

HostingSift — Mon, 23 Feb 2026 21:00:31 +0000

Why we chose Astro over SvelteKit for our hosting comparison platform

We're building HostingSift, a platform for comparing hosting providers side by side. Pricing tables, feature breakdowns, filters, user reviews. When we started, we had one decision that would shape everything else: SvelteKit or Astro?

We went with Astro. Here's why.

Some context first

HostingSift is a content-heavy site. We have 23+ hosting provider profiles, each with multiple plans, pricing tiers, feature specs, and user reviews. On top of that there are comparison pages, category listings, a recommendation quiz, and a blog.

The interactive parts are specific and well-contained: filtering plans by billing period, toggling comparison tables, authentication flows, review forms. Most of what users actually see is static content that doesn't need JavaScript to render.

This ratio matters. It shaped everything that followed.

SvelteKit was the obvious choice

We love Svelte. The reactivity model in Svelte 5 with runes is elegant. The developer experience is fantastic. SvelteKit is a mature, full-featured framework with file-based routing, SSR, API endpoints, form actions.

So why not just use it?

Because SvelteKit is an application framework. It assumes your pages are interactive by default. Every route ships a JavaScript bundle to hydrate the page client-side, even if the page is mostly static HTML.

You can work around this. You can set ssr: true and use +page.server.ts to keep data fetching on the server. You can prerender specific routes. But you're swimming against the current. The defaults push you toward shipping more JavaScript than a content site needs.

What Astro gets right for content sites

Astro starts from the opposite end. Zero client JavaScript by default. Every page renders as static HTML until you explicitly opt in to interactivity.

This is not a subtle difference. It changes how you think about building pages.

Islands, not full-page hydration

With Astro, we compose pages from .astro components (static HTML, zero JS) and Svelte components (interactive, with JS). The Svelte components are islands. They hydrate independently. The rest of the page is just HTML that the browser renders immediately.

Our hosting profile page is a good example. The page layout, provider description, specs table, pros and cons list, SEO metadata... all static Astro components. Zero JavaScript shipped. Then we drop in a PlanCard component with client:load for the interactive pricing table where users toggle billing periods. A ReviewForm for authenticated review submission. A HeaderAuth for login state.

---
import Layout from '../../layouts/Layout.astro'
import PlanCard from '../../components/PlanCard.svelte'
import ReviewSection from '../../components/ReviewSection.svelte'
import SpecsTable from '../../components/SpecsTable.astro'

const { hosting, plans } = await fetchHostingData(slug)
---

<Layout title={hosting.name}>
  <article>
    <h1>{hosting.name}</h1>
    <p>{hosting.description}</p>

    <!-- Static HTML, no JS overhead -->
    <SpecsTable specs={hosting.specs} />

    <!-- Interactive islands, hydrate independently -->
    <PlanCard client:load plans={plans} />
    <ReviewSection client:load hostingId={hosting.id} />
  </article>
</Layout>

Each island hydrates on its own. If one fails, the rest of the page still works fine. In SvelteKit, the entire page is a single hydration unit.

Prerendering is the default, not an opt-in

In Astro's hybrid mode, pages are prerendered at build time unless you explicitly say otherwise. Our homepage, category pages, legal pages, blog posts... all static HTML files. Fast, cacheable, no server compute on each request.

For pages that need fresh data (hosting profiles with live pricing, filtered listings), we mark them as server-rendered. It's explicit and intentional.

SvelteKit takes the opposite approach. Everything is server-rendered by default. You opt in to prerendering per route. The mental model is reversed. For a site where the majority of pages can safely be static, Astro's default aligns better with reality.

We still write Svelte

This is what made the decision easy. Astro is not a replacement for Svelte. It's a composition layer around it.

All our interactive components are pure Svelte 5 with runes, stores, reactive state. We didn't lose anything from the Svelte ecosystem. We just moved the routing and page composition up to Astro, where it can make smarter decisions about what ships to the browser.

The pattern feels natural once you get used to it. Page structure lives in .astro files (templating with zero overhead). Interactive behavior lives in .svelte files (full reactivity where it's actually needed).

The tradeoffs we accepted

Astro is not a free lunch. Here's what we gave up.

No form actions

SvelteKit's form actions with progressive enhancement are genuinely nice. In Astro, we handle forms through our Hono API with client-side fetch calls. It works, but there's more boilerplate involved. We write onSubmit handlers and manage loading states manually where SvelteKit would handle the plumbing for us.

Two component models

Anyone working on the codebase needs to understand both .astro and .svelte files. When does something belong in Astro vs Svelte? The rule is straightforward (static content = Astro, interactive behavior = Svelte), but it's still a decision you make dozens of times a day.

View Transitions have rough edges

Astro's View Transitions look great but come with real gotchas. Inline scripts re-execute on each navigation. We spent more time than expected getting Google Analytics and vanilla-cookieconsent to behave correctly, adding guard flags to prevent double initialization. SvelteKit's client-side routing handles this more gracefully out of the box.

Separate API server

SvelteKit has +server.ts for API routes, tightly integrated with the framework. We chose to run a standalone Hono server for our API. This was intentional (the API will eventually serve a mobile app too), but it means two processes to manage, separate deployments, and CORS configuration that SvelteKit wouldn't need.

Where this paid off

The results justified the decision.

Our homepage ships about 40KB of JavaScript total. The interactive bits (provider grid, newsletter form) are small isolated bundles. In a SvelteKit setup, the framework's client-side router adds baseline overhead before any of our code even loads.

Server-side OG image generation fits naturally into Astro's endpoint model. We generate dynamic Open Graph images for every hosting profile, comparison page, and blog post using Satori and Sharp. It's just a standard API route that returns a PNG buffer. No special configuration needed.

Build times stay fast. Prerendering 50+ static pages, generating sitemaps, and compiling the Svelte islands takes under 30 seconds. Adding a new provider doesn't slow anything down because the build is mostly parallel.

The deployment question

This one doesn't get discussed enough.

SvelteKit works everywhere in theory. In practice, the smoothest path is deploying to Vercel. Rich Harris works there, adapter-auto detects Vercel out of the box, and the integration is polished. You can absolutely use adapter-node and self-host, but you'll be configuring things that Vercel handles for you automatically.

We wanted to self-host. Our stack runs on a single Hetzner ARM64 VPS: the Astro site, the Hono API, PostgreSQL, all behind nginx and Cloudflare. The whole thing costs about €5 a month.

With Astro, deploying to a VPS was straightforward. Install @astrojs/node, build, run with PM2. That's it. No adapter quirks, no platform-specific edge cases. The output is a standard Node.js server.

The cost angle is worth mentioning too. Platforms like Vercel and Netlify use usage-based pricing. The Pro plans start at $20-25 per month, but the real cost depends on traffic, serverless function execution time, and bandwidth. Overages are billed automatically. There are well-documented cases of bills spiking unexpectedly after traffic surges or bot crawls. For a content site that serves a lot of static pages, this pricing model works against you.

A fixed-cost VPS eliminates that variable entirely. Traffic can double or triple and the bill stays the same. If we outgrow the current server, the next tier up is still a fraction of what a managed platform would cost at equivalent traffic. We're not locked into any vendor's pricing model, and migrating to a bigger box is a straightforward process.

To be fair, managed platforms give you CI/CD, preview deployments, edge functions, and zero-config scaling. Those are real features with real value, especially for teams that don't want to manage infrastructure. The tradeoff is control and cost predictability versus convenience.

For us, a €5 VPS with full control was the obvious pick.

After several months in production

23 hosting providers, hundreds of plans, comparison pages, a quiz, a blog, user auth, admin panel. All running on that single Hetzner box.

The architecture has held up. New provider profiles are just data. New interactive features are new Svelte islands dropped into existing pages. New static pages are .astro files with no client-side cost.

Would SvelteKit have worked? Of course. For a more app-like product with dashboards, real-time collaboration, heavy client state, we'd pick SvelteKit without thinking twice.

But for a content-first site where interactivity is the exception rather than the rule, Astro with Svelte islands turned out to be the right call. Not because SvelteKit couldn't do it. Because Astro's defaults already pointed in the direction we wanted to go.

There's real value in not having to fight your framework.

I Built a Hosting Comparison Platform with Astro, Svelte 5 & Hono

HostingSift — Sat, 21 Feb 2026 08:59:10 +0000

I got tired of hosting comparison websites. You know the ones. "Top 10 Best Hosting 2024" articles that haven't been updated since 2022, prices that are completely wrong, and rankings that suspiciously always put the same provider first no matter what.

So I decided to build my own. Not a blog post with affiliate links, but an actual tool where you can filter by hosting type, compare plans side by side, and see prices that are actually current. After about six months of work, HostingSift is live and I figured I'd share what went into it.

Why This Stack

Astro in hybrid SSR mode was the obvious pick. Most pages (hosting profiles, categories, homepage) get prerendered at build time, which means they're fast out of the box. A few routes like the comparison tool need server rendering, and Astro handles that switch per-page which is really convenient.

For interactive bits I went with Svelte 5. I was on React before and honestly the new runes API ($state, $derived, $effect) won me over pretty quickly. No dependency arrays, no stale closures, components feel lighter. It took maybe a week to get comfortable with the mental model shift and after that I didn't look back.

The backend is Hono on Node.js. Think Express but with actual TypeScript support and better performance. It handles auth, the admin panel API, affiliate click tracking, all that stuff. Database is PostgreSQL with Drizzle ORM which has been solid for both queries and migrations.

Everything lives in a monorepo: apps/web, apps/api, packages/db, packages/email. pnpm workspaces glue it together.

Keeping Prices Up to Date

The whole point of the site is showing accurate pricing, so I built an automated pipeline that pulls plan data from each provider on a weekly schedule. Every plan, every billing period, every feature toggle. It compares incoming data against what's already in the database and upserts the differences. Each run also creates a snapshot, so if a provider quietly bumps their renewal price by $2/month, that gets recorded. Over time this builds a price history for every single plan.

Getting the data right for each provider was the biggest time sink. Every provider structures their pricing page differently. Some have clean layouts, others hide plans behind tabs and dropdowns, and a few change their page structure often enough that things break. You end up writing very provider-specific logic and accepting that maintenance is part of the deal.

Things I'd Do Differently

I'd spend more time on data validation early on. I almost "fixed" what looked like a pricing bug for one provider before checking their actual website. Turns out they give their biggest promotional discount to mid-tier plans, not the cheapest ones. Now I always verify against the source before touching anything in the database.

Svelte 5 + Astro is a great combo but the ecosystem is still catching up. Some things that are one-line solutions in React/Next don't have equivalents yet. The tradeoff is worth it though, the output is noticeably lighter and the developer experience is genuinely good.

Try It

HostingSift is live if you want to check it out. You can filter by hosting type, compare providers, see current prices. Still adding more providers and features so if something looks off or you have ideas, I'd love to hear about it in the comments.

DEV Community: HostingSift

VPS Price Per GB of RAM: 711 Plans Across 39 Hosts

How we counted

The cheapest gigabyte at each host

Renewal reshuffles the whole board

What 8 GB actually costs, host by host

Bigger boxes do not get you cheaper RAM

Why cheap RAM is cheap

These prices barely move

What I would actually buy

ARM VPS Hosting in 2026: More Cores for Less Money

The short version

What ARM hosting actually is and why it is suddenly everywhere

ARM vs x86: the real price-per-resource comparison

Hetzner CAX: the pure Ampere line

Netcup ARM G11: the most cores for the money

How much cheaper it is than the American clouds

What ARM is great for and what it is not

Where ARM works brilliantly

Where x86 is still worth it

Energy efficiency and the green angle

How to migrate to ARM without pain

Our recommendation

Frequently asked questions

Is an ARM VPS slower than x86?

Will WordPress run on ARM hosting?

Can I run Docker on an ARM VPS?

Why is European ARM so much cheaper than the American clouds?

Who is an ARM VPS not right for?

MCP Server Hosting: Where to Actually Deploy in 2026

What an MCP server is, in one paragraph

Three transport modes, three hosting profiles

1. Stdio (local only)

2. HTTP with Server-Sent Events (SSE)

3. Streamable HTTP (the 2025 spec update)

Picking the right host

Self-hosted on a VPS: the realistic baseline

The setup, briefly

PaaS deployment: less work, slightly more money

Serverless: cheap and fast, with caveats

The security part nobody likes talking about

1. No authentication on the MCP endpoint

2. Tools that take filesystem paths

3. Database tools with no row-level filtering

4. Rate limiting

Real-world architecture: MCP server in front of a SaaS API

Where MCP server hosting is going

The 30-second recommendation

Self-Hosted LLM on a $5 VPS in 2026: What Actually Works

The short version

Why self-host an LLM at all?

What "self-hosted LLM" actually needs

The $3 to $6 VPS plans that can run real LLMs

Provider deep dive

Contabo: the price-per-GB winner

Hetzner: no longer competing at this price

Netcup: the quiet competitor

What you will actually run on 8 GB

Practical setup in 15 minutes

When NOT to self-host

Quick comparison: which $5 to $7 VPS wins?

What changes this year

The verdict

Related reading

The Raw Power of Svelte 5 Runes: 70 Components, 25 KB, Full Reactivity

Svelte 5 Runes in Production: What We Learned Building 70+ Components

What runes are and why you should care

The reactivity model: what actually happens under the hood

How we built a reactive filter system with runes

The bridge pattern we use everywhere

$derived for computed filter state

The price slider: reactive all the way down

$effect: the cleanup story

The simplicity argument: less code, fewer bugs

$props: TypeScript-first component contracts

Bundle size: the actual numbers

What surprised us

What bites

Quick reference

Bottom line