Kamatera Cloud Servers: Configuring CPU, RAM and Storage Your Way
A practical guide to configuring Kamatera cloud servers, from choosing a CPU type and sizing RAM and disks to understanding hourly and monthly billing.
Kamatera cloud servers are built from individually chosen parts: you pick the CPU type, the number of vCPUs, the amount of RAM and the disks, rather than choosing from a short list of fixed plans. That flexibility is useful when a workload does not match standard sizes, but it also puts more sizing decisions in your hands. This guide walks through each setting and how to choose it sensibly.
Why configuration matters on Kamatera #
Most developer clouds sell servers in preset bundles, where memory, CPU and disk grow together. If your application needs a lot of memory but little CPU, a bundle forces you to pay for cores you will not use. Kamatera, a provider that has operated since the 1990s and runs data centers across North America, Europe, the Middle East and Asia, takes a different approach: each resource is a separate dial.
The result is closer to building a virtual machine to a specification than to buying a plan. For a broader look at the company and its services, see our Kamatera platform overview.
The four dials you control #
1. CPU type
The first choice is not how many cores, but what kind. At the time of writing, Kamatera groups its CPU options into several types that differ in how much of a physical core you get and how consistent the performance is:
| CPU type | What it means | Suited to |
|---|---|---|
| Availability (Type A) | Shared cores at the lowest cost per vCPU | Light web servers, test and staging environments |
| General Purpose (Type B) | Balanced performance for everyday production use | Most application servers and small databases |
| Burstable (Type T) | A baseline with the ability to burst under load | Workloads that are quiet most of the time with short peaks |
| Dedicated (Type D) | Cores reserved for your server | CPU-heavy or latency-sensitive production workloads |
Type names and definitions can change, so read the current descriptions in the server creation screen. The practical rule holds regardless: shared CPU types suit variable, low-intensity work, while dedicated cores suit sustained load where noisy neighbors would hurt.
2. Number of vCPUs
Count the threads your application can actually use. A single-threaded Node.js process gains little from eight vCPUs, while a database, a build server or a multi-worker Python application can use them well. Start with what monitoring or local testing suggests, then adjust. Adding cores to a busy server helps only if the software can run work in parallel.
3. RAM
Memory is usually the easiest resource to estimate and the most painful to get wrong. Add up the resident memory of each process you plan to run (application workers, database buffer pool, cache, operating system) and leave headroom for spikes and file system cache. If a Linux server runs out of memory, the kernel’s OOM killer will terminate processes, often the largest one, which is usually your database.
4. Disks
Kamatera servers use SSD storage, and you can attach more than one disk to a server. Separating the operating system disk from a data disk is a good habit: it keeps database files away from log growth on the system disk, makes resizing cleaner, and lets you snapshot or back up data on its own schedule. If you are unsure which storage model your data needs overall, our guide on object, block and file storage covers the trade-offs.
Worked sizing examples #
The following are starting points for thinking, not recommendations for every case. Measure your own workload before settling on a configuration.
- Marketing site or small WordPress install: a shared CPU type, a small number of vCPUs, modest RAM, and a single SSD disk. Put a CDN in front for static assets rather than scaling the server.
- API backend with a separate managed or self-hosted database: a general-purpose CPU type, vCPUs matched to the number of application workers, and RAM sized to the workers plus headroom.
- Self-hosted PostgreSQL or MySQL: prioritize RAM so the working set fits in the buffer pool, use a separate data disk, and consider dedicated cores if query load is steady.
- CI runner or build machine: more vCPUs and moderate RAM, with a disk large enough for caches. Hourly billing makes it reasonable to power such servers down when idle, as long as you understand what is still billed while stopped.
Choosing a location #
Kamatera lets you choose from many data center locations. Pick the one nearest the majority of your users for lower latency, or the one required by your data residency obligations. If users are spread widely, one well-placed server behind a CDN often beats several poorly utilized servers in different regions. Latency tests from the provider’s site or a simple ping from your users’ networks can settle close calls.
Operating systems and images #
The server builder offers common Linux distributions and Windows Server, along with preconfigured application images. Windows licensing adds to the cost, so choose it only when your software needs it. Once a server is configured the way you like, you can save it as an image and deploy identical copies, which is a practical way to standardize new environments.
How the pricing model works #
Kamatera prices each resource separately, so the total cost is the sum of your CPU type and count, RAM, disk capacity, operating system licensing, and any add-ons such as extra IP addresses, backups or managed services. The configurator shows the running total as you adjust each dial, which is the most reliable way to compare options.
You can generally choose between hourly billing, where you pay for the time the server exists, and monthly billing, which tends to be better value for servers that run continuously. Outbound traffic has its own allowance and rules, so check what is included with your configuration. Kamatera has advertised a free trial period for new customers; confirm the current terms and any limits on the official Kamatera website before planning around it.
Whatever the model, the principles of cost control are the same: delete what you do not use, right-size after measuring, and set up billing alerts. Our guide to cloud cost management with budgets, tagging and right-sizing goes into these habits in more detail.
Networking and security basics #
Each server can have a public network interface and one or more private networks, which Kamatera provides as VLANs you can create to connect your servers internally. A sensible layout exposes only a load balancer or web server publicly and keeps databases on a private network with no public address at all.
Beyond that, the essentials are the same as on any unmanaged cloud server:
- Use SSH keys instead of passwords and disable root password login.
- Configure a firewall so only required ports are reachable, and restrict SSH to known addresses.
- Apply operating system updates regularly, or enable unattended security updates.
- Enable backups or snapshots, and test a restore.
- Protect the account itself with two-factor authentication and separate users for each team member.
Getting started the official way #
Create your account directly on the Kamatera website, complete its identity and payment verification, and then open the Kamatera management console to create your first server. If your use case needs something the defaults do not allow, such as sending email from a server or a larger resource limit, contact Kamatera support through the official channels and follow its process.
Kamatera also provides an API and command-line tooling, so once a configuration works you can script repeated deployments rather than clicking through the builder each time.
When Kamatera is a good fit, and when it is not #
Kamatera suits teams whose workloads have an unusual CPU to memory ratio, who want dedicated cores without moving to bare metal, or who need a data center location that other developer clouds do not offer. It is less suitable if you want a large catalogue of managed services, such as serverless functions, managed message queues or data warehouses, in the same account. In that case, a hyperscaler may be simpler, even if the raw compute costs more.
Frequently asked questions #
How are Kamatera cloud servers different from fixed-plan VPS providers?
Instead of choosing a preset bundle, you set CPU type, vCPU count, RAM and disks independently. This lets you match the server to the workload, for example lots of memory with few cores, rather than paying for resources you do not need.
Which Kamatera CPU type should I choose?
Shared or burstable types suit light, variable workloads such as test servers and small sites. General-purpose types suit most production applications, and dedicated cores suit sustained CPU-heavy or latency-sensitive work. Check the current type descriptions in the console.
Can I resize a Kamatera server after creating it?
Yes, the configuration can be changed after creation, although some changes may require a reboot. Take a snapshot or backup before resizing a production server, and schedule the change for a quiet period.
Is hourly or monthly billing better?
Hourly billing suits short-lived and experimental servers. For servers that run all month, monthly billing is usually better value. Confirm the current rates and rules on the official pricing pages before deciding.
