Private Cloud
Build your organisation's cloud on your own network rules, and run it from one quota
Your organisation gets a CPU, memory and storage quota: create as many servers as you need inside it, run your own gateway, and bring your team in with their company accounts. Your data stays in Türkiye, and your invoice reflects resources used, not server count.
Why now
- You're past thirty servers, and every one of them is a separate order, a separate invoice line and a separate thing to track. When a new project needs three more, procurement starts from zero again. Private Cloud gives your organisation one quota, and your team creates and removes servers inside it from the portal.
- Your branches have shared the same MPLS network for years, yet cloud servers are still reached over an internet VPN. The link is slow and firewall rules live in two places. Your corporate circuit is connected straight into your cloud environment, and the cloud becomes part of the branch network.
- Last month a leaver's portal account turned out to be still active. With your identity provider connected to the portal, access is governed from your own directory: disable the account there and it's gone from the portal too.
- Your virtualisation licence renewal and your hardware warranties expire in the same year. Instead of rebuilding the data centre, you move the workloads onto the platform Nesnet runs and keep managing them with your own quota, network and permission model.
- Your customers want servers and networks from you, but building your own cloud doesn't add up at your size. With partner rights you create a sub-organisation for each customer, set its quota yourself and invoice under your own name.
What changes
| Today | With Nesnet |
|---|---|
| Every new server means another purchase request and another invoice line. | Your team creates servers of any size and number inside the quota, straight from the portal. |
| Branches reach cloud servers through VPNs built over the internet. | Your MPLS circuit is connected to the cloud, and branches reach cloud servers on their internal addresses. |
| Portal accounts are kept separately, and leavers' access gets forgotten. | Your team signs in with company accounts; an account closed in your directory is closed in the portal. |
| Every network rule change is a ticket to the provider and a wait. | You write NAT, firewall, VPN and load-balancer rules on your own gateway yourself. |
| Hardware refreshes, virtualisation licences and capacity plans each get their own budget line. | One monthly invoice lists vCPU, memory, storage and network items separately, and hardware refreshes are Nesnet's job. |
From today to live: how it works
- 1
Discovery call
Agree with Nesnet's team how many servers you need, which network segments, whether MPLS or VPN is involved and which identity provider you'll use. You leave the call with an initial quota size and a clear view of what drives the price.
- 2
Organisation and gateway created
Automation builds the organisation, the elastic allocation, the gateway and the first network in that order, verifying each step. The gateway firewall starts from deny-all.
- 3
Connections and identity
Internet egress is opened, and your MPLS circuit, office VPN and dedicated routing domain are connected if you need them. Your identity provider is added to the portal and your organisation administrator hands out roles.
- 4
Pilot and migration
Your team creates its first servers, or moves a non-critical system to try the setup. Servers can be uploaded as OVA or moved with migration tooling, and the rollback step for the real cutover is written beforehand.
- 5
Go-live and growth
Your services are published with public IPs and gateway rules. You track quota usage in the portal and ask for more as demand grows.
What you get
One quota, as many servers as you need
Your organisation gets an elastic quota with separate ceilings for CPU, memory and storage. Inside those ceilings you create servers of whatever size and number you like, and the bill follows the resources used rather than the server count.
Design your own network
Create separate segments for applications, databases and management, and isolate or route them as you see fit. Run DHCP from the gateway, on the network itself or through a relay, and set DNS and IP pools from the portal.
Your gateway, your rules
Source and destination NAT, firewall rules, IP sets, security groups, port profiles and static routes all live on a gateway that belongs to your organisation. A rule change is not a ticket to anyone; you make it in the portal and it applies straight away.
A gateway that starts closed
Your gateway is handed over with a deny-all firewall rule and logging switched on. Nothing gets in until you open it, and only your organisation's authorised people decide which service is published.
Bring your branches in over a private circuit
Your corporate MPLS or private circuit joins your cloud environment as an external network, connected by the same Nesnet team that built the platform. Branches then reach cloud servers on your own internal addressing, without ever touching the internet.
A routing domain of your own
On request your organisation gets a separate domain (VRF) with its own routing table. Your address plan never clashes with anyone else's, which matters for multi-branch organisations and for partners providing networks to their own customers.
Connect offices over VPN
Offices without a circuit connect to your cloud networks over IPsec VPN on your gateway. Tunnel settings, peer addresses and which networks can see each other are defined in the portal, with no extra appliance to buy for each new office.
Manage your public IPs yourself
Allocate and release addresses from your organisation's public IP quota on your own. Publishing a new service doesn't need a support ticket; as long as you stay within quota, it's done in the portal in minutes.
Spread traffic and shield your web apps
A load balancer attached to your gateway spreads traffic across several servers, and a web application firewall (WAF) protects your application from common attacks. Your organisation runs virtual services, pool members and certificates itself, in the same portal.
Sign in with your corporate directory
Any corporate directory that speaks SAML or OIDC becomes the portal's identity source. Staff sign in with their company account instead of another password, and a leaver's access drops out of the portal the moment it's disabled in your directory.
Just enough access for everyone
Your organisation administrator hands out roles such as organisation administrator, catalogue author, console-only access or Kubernetes cluster author. Letting an application team create servers doesn't mean letting it touch the gateway rules.
Launch servers from approved images
Build your organisation's template catalogue, share it internally, subscribe to an external catalogue and upload your own OVA or ISO files. Because every team starts from the same approved image, security settings and packages don't drift from server to server.
Servers, Kubernetes and GPUs on one network
Virtual servers, Kubernetes clusters and GPU servers run side by side in the same allocation. The database, the services and the AI model stay behind the same gateway, traffic between them never leaves for the internet, and everything is tracked against one quota.
Placement rules and boot order
An anti-affinity rule keeps two copies of an application on different physical hosts, so a single hardware failure can't stop both. For multi-server applications you define boot order, so the database comes up before the application server.
Over-quota requests stop at the door
Before a server is created, the request is checked against your quota; anything that would exceed it is refused up front, so you're never left with a half-built server that has a disk but won't start. Live quota usage in the portal lets you plan growth from data, not guesswork.
Split storage by purpose
Your allocation can hold more than one storage policy, and you choose which one each server's disks go on. Because quota is tracked per policy, a test environment filling its disk never eats into the space of your production servers.
A record of every change
The portal's audit trail shows who in your organisation changed which server, network or rule, and when. After an incident you check the record instead of asking around, and see the order in which the changes were made.
Offer cloud to your own customers
With the partner administrator role you create a separate sub-organisation for each customer and manage its users and quota on their own. Partners invoice their customers under their own name, while building and running the infrastructure stays with Nesnet.
Backup and disaster recovery in the same portal
Backup for the servers in your quota, and replication to another environment, are added through the Backup and Business Continuity products from the same portal. The backup plan sits right next to the screen where you create the server, with no separate software to buy and install.
Take your servers with you
Package and download your servers and catalogue templates in OVF/OVA, an open standard. Your organisation's images aren't locked into a closed format; they open in another virtualisation environment and can be kept as an archive copy.
Why Nesnet
The network boundary is yours
Every organisation has its own gateway, where NAT, firewall, VPN and load balancing are defined. On request your organisation gets a separate routing domain (VRF), and your corporate circuit attaches to that boundary. No other organisation's traffic passes through your gateway.
Your data stays in Türkiye
Private Cloud runs on Nesnet's infrastructure in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara data centres. You know which country and which facility holds your servers and data; nothing is moved to a region abroad.
Provisioned by verified automation, not by hand
Your organisation, allocation, gateway, first network and internet egress are built by Nesnet's automation in repeatable steps. Each step is read back and verified after it completes, so no undocumented hand-made setting is left behind.
Touching the wrong tenant is blocked in code
The automation records which organisation owns every object it creates. Any operation on an object that doesn't match that record is refused, so another organisation's change can never land on your network or your servers.
Run by Nesnet, supported locally
The same Nesnet team builds and runs the hardware, the network and the virtualisation and portal layers. When you need an MPLS link, a routing domain or more quota, you ask Nesnet’s support team, in Turkish or English.
e-Invoice and partner billing
Invoices are issued as e-Invoice or e-Archive documents. Partners bill their own customers under their own name, and foreign payments drop off the finance team's list.
Example scenarios
An organisation bringing its branches in over MPLS
Situation
An organisation's head office and forty branches have shared one MPLS network for years. Cloud servers are reached over an internet VPN, the link keeps slowing down and security rules live in two places.
Outcome
The MPLS circuit is connected to the cloud environment as an external network, with a dedicated routing domain for the organisation. Branches reach cloud servers on their own internal addressing, and the VPNs and duplicate rule sets go away.
A company leaving its data centre before the licence renewal
Situation
A manufacturer's virtualisation licence and server warranties all expire in the same year. The renewal calls for a large upfront investment, and the team running the systems is two people.
Outcome
Non-critical systems move first and are tested, then ERP and file servers switch to Private Cloud over a planned weekend. The team keeps running its servers with its own quota, network and permissions, and the hardware refresh drops out of the budget.
A partner offering cloud to its own customers
Situation
An IT services firm wants to give its customers servers and networks, but isn't big enough to build and run its own data centre.
Outcome
Using the partner administrator role, the firm creates a sub-organisation for each customer and sets their quotas itself. It invoices under its own name, while running the infrastructure stays with Nesnet.
A software team bringing servers, Kubernetes and GPUs together
Situation
A software team keeps its database with one provider, its containers with another and its model experiments on a workstation in the office. That's three invoices and three security setups.
Outcome
All three move into one Private Cloud allocation: the database on a virtual server, services on a Kubernetes cluster, the model on a GPU server. Traffic between them stays behind one gateway, and everything shows up on one invoice.
An IT department giving a new project team its own space
Situation
A group's IT department wants to give a new digital-product team an environment where it can create its own servers but can't touch the production network.
Outcome
An isolated segment and a separate storage policy are set up for the team, which gets rights to create servers while gateway rules stay with IT. The audit trail shows every change the team makes.
Who does what
| Nesnet | You |
|---|---|
| Builds your organisation, allocation, gateway, first network and internet egress with verified automation. | Manage users and roles inside your organisation and connect your identity provider. |
| Connects your MPLS circuit and optional routing domain into the network layer. | Design your network segments and write your NAT, firewall, VPN and load-balancer rules. |
| Hands over your gateway with a default-deny firewall and makes the assignment the load balancer needs. | Decide which server runs at which size and on which storage policy within your quota. |
| Runs the physical servers and the virtualisation, storage, network and portal layers, applying patches and upgrades step by step with a rollback path. | Keep the operating systems and applications inside your servers up to date, and choose your backup plan. |
| Handles your quota increase requests and bills usage line by line. | As a partner, manage your sub-organisations, their users and their quotas. |
Who it is for
Corporate IT teams that design their own network
Teams that want to write their own segments, NAT, VPN and firewall rules. Private Cloud hands them a gateway of their own and the rights to run it, with no ticket for every rule change.
Organisations whose branches run on MPLS
Organisations whose head office and branches already share a private circuit. The cloud joins that network like another branch, so cloud servers are reached over your own internal addressing rather than the internet.
Companies leaving their own virtualisation estate
Companies facing a hardware warranty and a virtualisation licence renewal in the same year. Once the servers move, quota, network and permissions are run the way the team already works, and the hardware refresh disappears from the budget.
Partners selling cloud to their customers
IT service firms that provide servers and networks to their own clients. A partner administrator role creates a sub-organisation per customer, a dedicated routing domain is available on request, and invoices go out under the partner's own name.
Software teams with mixed workloads
Teams with a database on a virtual server, services on Kubernetes and a model on a GPU server. All three sit inside one quota, behind one gateway, on one invoice.
May not be the right fit
If your servers must run on hardware physically reserved for you, Private Cloud does not meet that requirement: every organisation's quota is carved from the same physical platform, and the separation is logical. For that requirement, Nesnet can install the same platform in your own data centre as a product-plus-consulting engagement.
If you're starting with a handful of servers and don't need a network design, Virtual Servers is less work, and you can move to Private Cloud on the same platform later.
If your application already ships as containers and you'd rather not manage servers at all, Managed Kubernetes or Nesly Serverless Platform is the better starting point.
Under the hood
Private Cloud builds on the organisation model of a multi-tenant cloud portal. Your company is created as its own organisation in the portal, which is your boundary for users and permissions. Inside it sit one or more resource allocations that use an elastic allocation model, with separate ceilings for CPU, memory and storage. In the software-defined network your organisation's gateway runs active-standby with distributed routing enabled, and a dedicated routing domain (VRF) plus your MPLS circuit can be added to it. Load balancing and a web application firewall (WAF) come from a load-balancing layer attached to your gateway. Storage is distributed and all-NVMe. Nesnet adds its own automation on top: organisation, allocation, gateway, network and internet egress are built in repeatable steps, each verified separately, while an ownership record prevents any change from landing on the wrong tenant. Nesnet also ships its own portal plug-ins — self-service backup, SSL VPN and Kubernetes applications.
Building blocks
- Cloud portal and API
- organisations and resource allocations, elastic allocation, a redundant portal and API
- Software-defined network
- your own gateway, an optional dedicated routing domain (VRF), distributed routing
- Load-balancing layer
- load balancer and WAF on your gateway
- Distributed NVMe storage
- all-NVMe, with a quota per storage policy
- Virtualisation layer
- restart after failure, automatic load balancing
- Nesnet automation
- verified provisioning steps and a per-tenant ownership record
How it compares
| Option | When it is the right choice |
|---|---|
| Nesnet Virtual Servers | If you have a few servers and need neither your own network design, your own identity provider nor an MPLS link, going server by server is simpler. When you grow, you can move to Private Cloud on the same platform. |
| Virtualisation in your own data centre | If ownership and physical location of the hardware must stay with you, running your own environment can be the right call. In that case Nesnet can install the same platform at your site as a product-plus-consulting engagement. |
| Colocating your own hardware | If you already own servers and want to keep managing them yourself, colocation makes sense. Hardware failures, capacity planning and maintenance of the virtualisation layer stay with you in that model. |
| Global hyperscalers | If you need regions in several countries and a broad managed-service catalogue, a hyperscaler fits better. If keeping data in Türkiye and connecting your network directly over MPLS are the priorities, Private Cloud is the better match. |
Technical specifications
| Tenancy model | Organisation + one or more resource allocations |
|---|---|
| Allocation model | Elastic; separate CPU, memory and storage ceilings, thin provisioning |
| Storage | All-NVMe |
| Storage quota | Per policy; one filling up doesn't affect another |
| Nature of separation | Logical: quota + tenant boundary + network; no dedicated hardware |
| Quota check | Before a server is created; over-quota requests refused |
| Usage visibility | Quota and usage in the portal |
| Network boundary | Your own gateway (NAT, firewall, VPN, load balancing) |
|---|---|
| Gateway resilience | Active-standby, distributed routing enabled |
| Separate routing table | Optional, organisation-specific VRF |
| Corporate circuit | MPLS / private circuit as an external network |
| Network types | Routed, isolated; DHCP (gateway, network, relay), DNS, IP pools |
| Gateway services | NAT, firewall, IP sets and security groups, port profiles, static routes, IPsec VPN |
| Default firewall | Deny all, logging on |
| Public IPs | From organisation quota, self-service allocate / release |
| Load balancing and WAF | Run by the organisation itself |
| Identity provider | Your SAML / OIDC provider |
|---|---|
| Roles | Organisation administrator, catalogue author, console only, Kubernetes cluster author |
| Catalogue | Create, share, subscribe to external catalogues, upload OVA / ISO |
| Partner model | Partner administrator role, sub-organisations |
| Workloads in one allocation | GPU-enabled servers and Kubernetes clusters |
| Portal | Redundant; stays up if one part of it drops |
| Failure handling | Restart after a host failure, load balancing |
| Portability | Download servers and templates as OVF/OVA |
| Data centres | Equinix Istanbul (Dudullu), Türk Telekom Ankara |
If something breaks
A physical host fails
High availability restarts the virtual machines from the failed host on other hosts in the cluster, and load balancing then redistributes the load.
Part of the portal goes down
The portal layer runs redundantly, so the portal and API stay up and your team keeps managing its servers.
A gateway node goes down
Your gateway runs active-standby; the standby node takes over with the same rules.
A disk or host is lost
Storage data is replicated across physical hosts according to policy, so a single disk or host failure doesn't mean data loss.
Your quota runs out
A new server request is refused at the quota pre-check. You're never left with a half-created server that has a disk but won't power on.
For a disaster
Backup and replication infrastructure is installed on the platform; both are added to the servers in your quota through the Backup and Business Continuity products.
Frequently asked questions
Pricing and first steps
Pricing
Private Cloud is billed monthly based on the resources you use. Charges come from the vCPU, GB of memory and GB of NVMe storage consumed, not from the number of servers; gateways, load balancers, intrusion detection and prevention, public IPs and internet bandwidth are separate line items.
What the price depends on
- vCPU and memory (GB RAM) consumed
- NVMe storage (GB)
- Number of gateways, and intrusion detection and prevention (IDS/IPS) per gateway
- Number of load balancers
- Number of public IP addresses
- Internet bandwidth (Mbps)
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.Your network and server needs are worked out in one call, with a quota proposal and a price.
- 3.Your organisation is created, and your team signs in with company accounts to launch its first servers.
Draw the boundaries of your cloud yourself
Once an organisation runs many servers, what it needs isn't one more server but one place to govern its network, its users and its resources. Tell Nesnet's team about your network and your servers; you'll hear back the same business day, and your organisation is set up around that plan.