Skip to content
  • Independent cloud account marketplace
  • Options and USD prices shown before checkout
  • Support available before and after ordering
Provider Guides

Kamatera Explained: Cloud Servers, Data Centers, and Custom Configurations

How Kamatera is organised: the console and API, global data centers, server types A, B, D and T, custom CPU, memory and disk configurations, add-on services, and monthly versus hourly billing.

Kamatera is a cloud server provider that has been running its own infrastructure since the 1990s, with data centers in North America, Europe, Asia and the Middle East. Its distinguishing feature is configuration freedom: instead of picking from a fixed menu of plans, you choose CPU type, core count, memory and disk size independently and pay for that exact shape. This guide explains how a Kamatera account and console are organised, where its data centers are, how server types and custom configurations work, which add-on services exist, and what to check on billing and acceptable use.

Account, console and API

A Kamatera account is a single billing entity opened with a verified email, contact details and a payment method. The Kamatera Console is the web control panel: it lists servers by data center, shows resource usage and invoices, and is where you create servers, networks, disks and firewall rules. The console also has a built-in remote console for each server, which is the way in when SSH or RDP is unreachable.

For automation Kamatera exposes a REST API with per-account API keys, a command-line client, and a Terraform provider. Server creation through the API mirrors the console form: pick a data center, a server type, CPU and memory, disks, an image, and networking options. API keys carry full account rights, so store them like any other secret and rotate them if a machine that held them is retired.

Enable two-factor authentication on the console login. Kamatera also supports additional user logins with role-based access for teams, so the account owner’s credentials do not need to be shared.

Data centers

Kamatera operates a global set of data centers; the current list is on its data centers page. Locations at the time of writing include New York, Texas and other United States sites, Toronto, Amsterdam, London, Frankfurt, Hong Kong and several in Israel, where the company is headquartered. Pricing is the same across locations for the same configuration, which simplifies choosing purely on latency to your users.

Each server lives in one data center along with its disks. Private networking (VLANs) is also per data center, so a multi-site design talks over the public internet or a VPN you run yourself. There is no availability-zone concept inside a location; if you want physical separation you deploy in two data centers.

Server types and custom configurations

The core product is the cloud server, a virtual machine described on the cloud servers page. Rather than fixed plans, you build a configuration from parts:

  • Server type, which sets how CPU is allocated. Kamatera labels these with letters: Type A (availability, shared cores for light workloads), Type B (general purpose), Type D (dedicated cores reserved for your server) and Type T (burstable, for workloads that idle most of the time and spike briefly).
  • vCPU count and memory, chosen independently, so a memory-heavy cache server and a CPU-heavy build server can be sized differently without paying for the unused half of a bundle.
  • Disks on SSD storage, sized in increments, with additional disks attachable later.
  • Image: a plain Linux distribution or Windows Server, or one of the service images with software preinstalled such as cPanel, Plesk, Docker, WordPress or a database server. Windows and control-panel licences are added to the monthly price.
  • Network options: public IPv4, additional IPs, and private VLAN membership.

Configurations can be changed after creation. Scaling CPU or memory up or down is a restart, not a rebuild, which is useful for right-sizing after you have seen real load.

Server type CPU model Typical use
Type A Shared cores, lowest cost Small sites, monitoring agents, dev boxes
Type B General purpose shared cores Web and application servers
Type D Dedicated cores Databases, sustained CPU work
Type T Burstable Idle-mostly services with short peaks

Add-on services and typical workloads

Around the server sit the usual building blocks: block storage volumes, load balancers, a network firewall service, private networks, scheduled backups and on-demand snapshots. Kamatera also sells managed services where its staff handle operating system maintenance, monitoring and backups for a monthly fee, and a cloud desktop product for hosted Windows workstations.

Typical customers run web hosting for agencies (cPanel or Plesk on a Type B server), application backends with a dedicated-core database server, VPN and remote-access gateways, game or voice servers close to a specific region, and Windows workloads that need a licensed Windows Server without buying hardware. The Israeli and Middle East locations make it a common choice for teams serving that region.

Billing, trials and acceptable use

Kamatera offers two billing models per server. Monthly billing charges a fixed amount for the configuration and includes a monthly traffic allowance. Hourly billing meters the server while it exists and charges traffic separately, which suits short-lived test machines. Charges accrue to the account and are settled against the payment method on file, and invoices are available in the console. Kamatera has offered trial credit to new customers at various times; the amount and conditions are set by Kamatera and change, so check its current terms rather than an older article.

The CloudAccountHub product page lists two variants, Kamatera Free Trial and Kamatera Port 25 Open. Each label states the listing as written and nothing beyond it. Outbound SMTP on port 25 is filtered by default on most cloud providers to limit spam, and whether it is enabled on a particular account is a provider decision. Any mail sent from a server, on any port, must comply with Kamatera’s acceptable use policy and with anti-spam law such as CAN-SPAM, CASL and GDPR; for application mail the reliable path is an authenticated relay through a transactional email service on port 587.

Where to go next

More from the Cloud Library

Telegram