Procurement of servers, vCPU, memory, disk and network capacity. You choose the data centre location, the resources are sized by measurement, and your team runs it — or we do.
Organisations whose storage or compute demand is growing usually face two routes: buy hardware, or rent it. This page covers the second — cloud server rental, data centre services and infrastructure procurement. We provision vCPU, memory, disk and network capacity allocated to you, settle the data centre location with you, and hand the infrastructure over running.
What distinguishes this service is that it is raw infrastructure. The server is your resource: you decide what runs on it, how it is configured and who administers it. If you would rather hand the operational side over as well — setup, deployment pipeline, monitoring, incident response on our side — that work belongs to our managed hosting service. The two do not replace each other; they fit together.
What follows, in order: which procurement model suits which workload, the technical and legal consequences of data centre location, how capacity is sized by measurement, scaling and redundancy decisions, storage tiers, network and access design, where cost actually leaks from, the build and handover process, and how to avoid being locked to a provider.
All three have different cost curves. The right answer depends on how predictable the workload is and how many years it will run; there is no universal winner.
vCPU, memory and disk carved out of a virtualised pool. The upfront cost is close to nothing, the server is ready in minutes rather than weeks, and growing it is a matter of a reboot. In exchange the monthly charge never stops, and over a long enough horizon the total cost of ownership is the highest of the three.
Best fit: Projects whose requirements are still moving, fluctuating traffic, test and development environments, work that has to start now.
You buy the machine; it either lives in your building or in a rented rack at a data centre. The upfront cost is high, procurement is measured in weeks, and a hardware failure becomes your problem. In return the monthly line item drops to power, space and maintenance, and across a three to four year window the arithmetic reverses.
Best fit: Long-lived workloads with a known, steady load. Disk-heavy databases, large file archives, constant compute jobs.
The whole machine is allocated to you, but the provider still owns it. No neighbours, no virtualisation layer, predictable disk and CPU behaviour. You get physical machine performance without a capital purchase; the monthly figure sits above a cloud instance and below the amortised cost of hardware you own.
Best fit: Systems that consume heavy resources continuously but should not become a capital expense; software licensed per physical core.
In practice the calculation runs like this: the purchase price of hardware is divided by its expected life and reduced to a monthly figure, then power, rack space, spare parts and maintenance are added. That number is compared against the monthly cost of renting. Two items are usually left out of the comparison: how long the system stays down when hardware fails, and what a procurement delay costs the project. What renting actually sells is not capacity but the transfer of those two risks.
Confusing the two produces the wrong expectation. The work on this page is the infrastructure itself; getting your application installed and operated is a separate scope.
This page: renting capacity
Hosting page: operations
The difference between Turkey and Europe is not only milliseconds. For systems processing personal data, location either opens a legal question or avoids it entirely.
If your users are inside Turkey, a Turkish location typically buys you an advantage measured in tens of milliseconds. A European location means several times that round trip for the same user. That gap is felt in an interactive corporate panel and not felt at all on a server running nightly batch jobs. The decision follows the workload, not the brochure.
The country a server sits in is not purely a technical preference. If personal data will be processed on a server outside Turkey, the cross-border transfer question opens under KVKK: which legal basis applies, what the privacy notice says, and what the data processing agreement covers all have to be settled. Keeping data inside Turkey is the choice not to open that question at all.
For systems that process no personal data, anonymised analytics, secondary copies or applications serving European users, a European location is reasonable and often cheaper. What is wrong is making the choice without noticing that a choice was made.
Application servers in Turkey with archives and cold copies in Europe is a common split. We produce an inventory of which data class lives where and put it in writing; that inventory is exactly what an audit asks for.
Sizing is not picking a package from a catalogue; it is measuring the real requirement and writing down what meets it. Each of the items below is budgeted separately.
More cores do not make every workload faster. An application that runs on a single thread is no quicker on eight cores than on one. We measure whether the bottleneck is actually the processor first, and in most web applications it is not.
This is the resource that runs out most often, and when it does the system does not slow down, the process gets killed. Database cache, the application working set and the operating system share are each budgeted separately. Being frugal about memory produces the most expensive kind of outage.
Anything with heavy random reads and writes — databases, queues, search indexes — needs NVMe; mechanical disk chokes there. Large files read sequentially, media archives and backups are served perfectly well by HDD or object storage at a fraction of the cost. Putting both on the same volume means paying premium prices to store cheap data.
Capacity and speed being separate dimensions is the most commonly missed point. With some providers IOPS scales with volume size, so buying a small disk quietly caps your throughput too. We check that coupling before sizing a database volume.
The speed of the network interface and the monthly traffic allowance are two different line items. For systems that serve media, ship backups or carry heavy API traffic the allowance matters as much as the speed, and it is usually where the billing surprise originates.
A server bought on a guess ends up in one of two states: burning money at a quarter of its capacity, or falling short on the busiest day and causing an outage. Where a system already exists we observe it for a period and derive the real peaks; where none exists, starting small and growing against measurement costs less than buying big on day one.
The wrong answer is expensive: a distributed architecture built before it is needed takes back more in complexity than it ever returns.
Adding cores, memory or disk to the same machine. It requires no change to the application, which makes it the cheapest and fastest answer — the cost is a short reboot. It holds until a single machine runs out of headroom, and most corporate workloads never come close to that ceiling.
Going horizontal means a load balancer in front and shared session handling behind. The application has to be ready for that; if it is not, the code comes first. The honest reason for going horizontal is usually not capacity but continuity: staying up when one machine dies.
Autoscaling was designed for systems whose load swings by multiples within a day. On a corporate application with predictable traffic it buys a limited amount of money and brings setup complexity, harder debugging and a class of strange scaling-related faults. Where the need is absent we do not build it, and we write down why.
Capacity added for a campaign, a season or a migration tends to stay added. A scaling plan defines the moment of coming back down as well as going up; otherwise a temporary need turns into a permanent line item.
The continuity decision is arithmetic rather than sentiment: the cost of a day of downtime against the annual cost of redundancy.
A full copy of the server at a point in time. Taken before an upgrade, a version change or any risky operation so that a bad outcome can be reversed in minutes. A snapshot is not a backup strategy — it lives on the same infrastructure and was never designed for long retention.
The copy of your data that sits in another data centre, preferably in a different geography. When an entire region becomes unreachable, that copy is all you have. How often it is refreshed is exactly how much data loss you have agreed to accept.
One server is cheap until it stops. The number to calculate is not the monthly price of the second machine but what a full day of downtime costs the organisation. In some businesses that figure clears the second server’s annual cost in a single day; in others it never does. The decision comes out of that comparison.
We write down in advance how quickly the system has to be back if the server is lost entirely. That number is a constraint that shapes the build, not an aspiration: a four-hour target and a four-day target produce two completely different architectures. Once written, it is verified by a drill.
Most of a storage bill comes not from having too much data but from keeping it in the wrong tier. Growing volume calls for a layered approach.
A disk attached directly to the server. The operating system sees an ordinary volume, and database files, application directories and anything that needs low latency live here. It is fast, it is the most expensive layer per gigabyte, and it is tied to one machine.
What lives here: Databases, application files, working space.
A layer where files are addressed over HTTP and capacity is effectively unbounded. It is not bound to a server, several systems can read the same data, and a delivery network can cache in front of it. The cost per gigabyte is markedly lower than block.
What lives here: Media files, user uploads, backups, log archives.
The cheapest option for data that is rarely read but cannot be deleted. Retrieval latency can be measured in minutes and reads may carry a charge; in exchange the storage cost sits far below the other tiers. Records under a legal retention obligation belong here.
What lives here: Legal retention, historical backups, project archives nobody will open again.
As data grows, the movement between these three tiers has to become a rule: after how many days which data drops a tier, how retrieval from archive works, what the deletion policy is. Without that rule the outcome is predictable — everything stays on the most expensive tier and the bill grows linearly with the data.
For detail on the object storage side and S3-compatible setups see S3 storage and backup, and for terabyte and petabyte scenarios, file servers and storage networking see enterprise storage solutions.
On rented infrastructure the first layer of security is the network. The arrangement below is in place when the server is handed over; it is not something added later.
The convenience of usage-based billing is also its weakness. When nobody can see where the spend comes from, nobody stops it.
A cloud invoice is never one line: instance hours, disks, snapshots, IP addresses, load balancers, backup retention and traffic are all billed separately. Each looks small and the total lands well above expectation. The way to avoid a surprise at month end is to list the line items before you start.
Putting data into a cloud is usually free; taking it out is not. For systems that serve media, pull backups or push data to another provider, egress can grow larger than the server bill itself. It shapes architecture directly: using a delivery network, keeping data close to where it is consumed and cutting needless copying all reduce it.
An alert is configured against a defined threshold. The point is not to cut the bill off but to find out mid-month; a runaway job or a misconfigured backup task is usually seen for the first time through that alert.
Test servers spun up once and forgotten, detached volumes, idle IP addresses and stale snapshots all bill every month. Producing a periodic inventory and shutting them down is, in most organisations, the fastest-paying cost exercise available.
A long-term commitment brings a meaningful discount on capacity that is certain to run continuously. The risk is being locked in when the requirement changes, so we only recommend commitments for workloads whose permanence has been confirmed by measurement.
The largest share of cost usually comes not from too much capacity but from the wrong tier. Holding a hundred gigabyte media archive on fast block storage when it belongs in object storage means paying several times over for the same bytes.
Raw infrastructure does not mean handing over the keys to an empty box. These six steps run in the same order on every build.
What will run, how many users are expected, what the data volume is today and twelve months out. Where a system already exists, real resource usage is observed. The output of this step is a sizing table, not a quote.
The cost curves of cloud, rented physical and owned hardware are compared for this specific workload. The data centre location is settled together with its KVKK consequences and put in writing.
The server is handed over with the chosen operating system installed and baseline hardening done: firewall defined, key-based access enabled, time synchronisation and automatic security patching configured. Private networking, disk attachments and the backup job are handed over ready.
Administrative access belongs to you. Who connects with what privileges is listed, co-managed setups get a separate account per person, and changes are recorded. Where the access credentials are stored is written down too.
From here your own team can run it; the infrastructure is yours in raw form. If you would rather hand management over, monitoring, backup verification, patching and incident response move to our side. Moving between the two models later is possible.
In the early months real usage is compared against the sizing table. Over-provisioned resources come down, undersized ones go up. A capacity plan is a working file kept current, not a document produced once and shelved.
A healthy infrastructure relationship depends on the exit being open. A system built so that it cannot move takes your negotiating position with it.
The data stays yours
Database dumps, file archives and configuration files remain exportable on demand. No critical data is held only in a single provider’s proprietary format.
Configuration travels
The server build is defined in repeatable scripts rather than remembered clicks. The same setup can be rebuilt at another provider quickly, and the knowledge does not live in one person’s head.
Provider-specific services are chosen deliberately
A provider’s managed services reduce operational load and increase the cost of leaving. Using them is not wrong; using them without noticing is. How hard each component would be to move is written down at the start.
The migration scenario is rehearsed
Just as a backup that has never been restored is not a backup, portability that has never been tried is only a claim. For critical systems we periodically verify that the stack can come up in a different environment.
Server capacity runs monthly and is itemised: processor, memory, disk type and size, redundancy level, backup volume, monthly traffic and location. The build, hardening and handover are a one-off piece of work with a scope defined up front. We do not publish a fixed list price because those items combine differently in every organisation; after we discuss the requirement we produce an itemised quote. How each line grows as you grow is written into that quote as well, so nothing is discovered at month end. If you decide to leave, the server image, data backup and configuration files are handed over.
In a data centre in Turkey or Europe, as you prefer. Location is a decision with both latency and legal consequences: for systems processing personal data, a location outside Turkey opens the cross-border transfer question under KVKK. Which data class sits where is put in writing before the contract. A mixed setup is also possible — application in Turkey, archive in Europe.
For cloud servers, delivery within the same business day including setup and baseline hardening is usually achievable. For rented physical servers the timeline depends on hardware allocation and is measured in days. If hardware has to be purchased and racked, the conversation moves to weeks. Starting on a cloud server and moving to a physical machine later is a common path when the need is urgent.
Yes — that is the default model on this page. The infrastructure is delivered in raw form, administrative access is yours, and everything after handover is your team’s call. If you would rather hand management over, the managed model covering monitoring, backup verification, patching and incident response is our hosting service. Switching between the two models later is possible.
First we measure which resource is saturated — processor, memory, disk throughput or network. In most cases the answer is to grow the existing machine, which ends with a short reboot and needs no application change. When a single machine approaches its ceiling, or when continuity rather than capacity is the driver, we discuss spreading the load to a second server. The cost difference is shared in writing before either decision.
Server rental itself does not include backups; backups consume their own resources and are planned separately. Snapshots and a periodic backup job are handed over configured, with retention and frequency agreed with you. The storage cost of backup volume is budgeted from the start — it is one of the line items that most often grows into a surprise. And a backup has to be restore-tested: one that has never come back is not a backup.
Yes. We start with an inventory: servers, volumes, databases, file volumes, DNS records and external dependencies. The new environment is built in parallel, data is copied, everything is tested, and the cutover completes with a short switch. The most overlooked item in a migration is egress cost; the volume to be pulled out of the old provider is calculated up front.
Cloud servers can run on a monthly arrangement; a long commitment is not required. Long-term commitments bring a meaningful discount but are only recommended for workloads whose permanence has been confirmed by measurement. On rented physical servers the term relates to hardware allocation and is usually longer; the term and the exit conditions are stated explicitly in the contract.
Pricing comes out of the sizing table rather than a single list: vCPU, memory, disk type and size, redundancy level, backup volume, monthly traffic and location. Those items change the figure, which is why we do not publish a fixed price here. After we discuss the requirement we produce an itemised quote, and it states what each line covers and how it will grow if you do.
Data measured in terabytes becomes both expensive and fragile when it is forced onto server disks. The right approach is layered: frequently accessed, latency-sensitive data on server disk, media and backups in object storage, rarely read records in an archive tier. Our enterprise storage and S3-compatible storage pages go into the high-volume scenarios in detail.
Not in the default build. Management access sits behind a VPN, the database and internal services are reachable only over the private network, the firewall starts closed and every open port is defined with its justification. Only the service that genuinely has to be public faces outward.
Related services
Object storage, S3-compatible setups and keeping backups on a layer separate from the server.
Terabyte-scale volumes, file servers, storage networking and layered archive design.
Have us operate the infrastructure too: setup, deployment pipeline, monitoring and incident response.
Identity and permission design, configuration review and hardening of cloud resources.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.