Kamatera Cloud Servers: Built by the Resource, Not the Plan

Almost every cloud provider sells fixed bundles: this many cores with this much memory and this much disk, take it or leave it. If your workload wants eight cores and 4 GB of RAM, you buy sixteen gigabytes you will not use.

Kamatera's proposition is that you specify each resource independently. That single difference defines where the platform is a good fit.

How configuration actually works

When you create a server you choose four things separately:

1. CPU type — Availability (oversubscribed, cheapest), General Purpose (balanced), Dedicated (guaranteed cores), or Dedicated with higher clock for latency-sensitive work.
2. Core count — within the range allowed by the chosen CPU type.
3. Memory — in gigabyte increments, largely independent of core count.
4. Storage — one or more SSD volumes, sized as you need, with additional volumes attachable.

The CPU type is the choice that matters most and is most often got wrong. Availability cores are oversubscribed and are genuinely fine for batch work that can tolerate variable throughput, and genuinely unsuitable for anything user-facing. Dedicated cores are guaranteed and cost accordingly.

Global zones

Kamatera operates data centres across North America, Europe, the Middle East and Asia. The zone list is wider than most independent providers of its size, which is the platform's second differentiator: you can place a small, precisely sized server close to a specific audience without moving to a hyperscaler.

Zone choice affects available CPU types and pricing, so confirm the combination you want exists in the zone you need rather than assuming parity.

Managed services and what is included

Kamatera layers optional services on top of raw servers: managed cloud firewall, load balancers, private networking, block storage, and a managed service tier where their team administers the operating system for you.

That managed tier is unusual at this price point and is worth considering for teams without a systems administrator. It is a service relationship rather than a product feature, so scope it explicitly.

Outbound SMTP and port 25

Like every reputable provider, Kamatera restricts outbound port 25 by default on new accounts. Environments where it has been opened are described that way precisely because it is not the default state.

If you need to send email, the responsible architecture is almost always an authenticated relay on port 587 with SPF, DKIM and DMARC aligned to your sending domain, plus honest list hygiene. Direct port 25 sending makes you responsible for your own IP reputation, complaint feedback loops and compliance with anti-spam law in every jurisdiction you send into. The deliverability guide sets out what that commitment involves before you take it on.

Where the configurability pays off

The model is worth real money in a few specific shapes:

• High core, low memory — build servers, video encoding, scientific computation. You buy cores without the memory tax.
• Low core, high memory — caches, in-memory indexes, single large database instances.
• Unusual disk ratios — log aggregation, media libraries, anything where storage dominates.
• Precise geographic placement — a small server in a specific country without a hyperscaler's minimum.

Where it pays off less is the ordinary web application with a balanced profile. For that, a fixed-plan provider such as DigitalOcean or Linode is simpler and often cheaper, because the plan is already shaped for that case.

Evaluating a Kamatera environment

1. Confirm the zone, and that it is the zone you actually want.
2. Confirm the CPU type available, not just the core count.
3. Check the account's server and resource limits.
4. Confirm the state of outbound port 25 if email matters.
5. Verify who holds the account credentials and API keys.
6. Check the billing method and cycle.

A Kamatera account that is limited to Availability cores in a zone far from your users is a different proposition from one with dedicated cores where you need them. The listing states which configuration applies.

Frequently asked questions

Is an Availability core usable for production? For background work that tolerates variable throughput, yes. For anything a user waits on, no.

Can I change a server's specification after creation? Yes — resources can be adjusted, typically with a reboot. This is one of the platform's practical advantages over fixed plans.

How does pricing compare to fixed-plan providers? It wins where your requirement is lopsided and loses where it is balanced, because a fixed plan is essentially a pre-negotiated discount on a common shape.

Is the managed service tier worth it? For teams without systems administration capacity, often yes — but scope exactly what is covered before relying on it.

Current configurations are listed on the Buy Kamatera Account page.