TinyServers Blog

Category: Tutorials

  • How to Choose a Dedicated Server in Romania (2026)

    Choosing a dedicated server in Romania is mainly a capacity and operations decision, not a search for the longest specification list. Start with the workload you must run, measure its CPU, memory, storage and network requirements, then leave enough headroom for traffic peaks, maintenance and growth. This guide explains the decision process and maps common workloads to the current TinyServers Ryzen plans hosted in Bucharest.

    Compare dedicated servers in Romania or use the checklist below before you order.

    VPS or dedicated server?

    A VPS is usually the efficient choice for small websites, development environments, low-volume APIs and workloads that need to scale gradually. A dedicated server becomes useful when you need predictable access to physical CPU cores, larger memory capacity, more local storage, stronger workload isolation or the freedom to run a dense container or virtualization platform.

    VPS and dedicated server decision comparison
    Decision factor VPS Dedicated server
    Best fit Small and medium workloads, staging, websites and lightweight services Sustained production workloads, databases, game servers, CI/CD and virtualization
    Resource model Virtual CPU, RAM and storage allocated on a shared host Physical CPU, memory and disks assigned to one customer
    Scaling Easy to start small and move between plans More headroom per node, but hardware changes require planning
    Provisioning Normally available in minutes Prepared individually; TinyServers normally provisions in 48–96 hours
    Operations Lower entry cost and simpler capacity planning More control, with greater responsibility for monitoring, backups and recovery

    If your application runs comfortably on a VPS and monitoring shows stable CPU, RAM and disk latency, moving to bare metal may add cost without solving a real problem. If the VPS repeatedly reaches its limits, suffers from sustained CPU contention, needs much more memory or must host several isolated workloads, a dedicated server is easier to justify.

    Seven requirements to measure before choosing hardware

    1. Sustained and peak CPU usage

    Measure normal CPU utilization and peak periods separately. A workload that averages 20% but reaches 100% during imports, backups or traffic bursts needs different headroom from one that remains flat all day. Core count matters for parallel workloads such as build runners, containers and multiple game instances. Single-thread performance matters for applications that cannot spread work across many cores.

    2. Working memory, not only allocated memory

    Look at actual RAM consumption, file cache and swap activity. Databases and Java applications often use available memory productively, so consistently full RAM is not automatically a fault. Repeated swapping, out-of-memory events and process restarts are stronger signs that the node is undersized. Allow capacity for the operating system, monitoring agents and backup jobs in addition to the main application.

    3. Storage capacity and latency

    Capacity answers how much data you can keep; latency and throughput determine how quickly the application can use it. SSD is adequate for many entry workloads. NVMe is a better fit for busy databases, search indexes, build caches, container layers and applications that perform many small random reads and writes. Plan free space for logs, temporary files, updates and local backup staging instead of sizing the disk to current data alone.

    4. Network traffic and audience location

    TinyServers dedicated plans include an unmetered 1 Gbps port and one public IPv4 address. Hosting in Bucharest is a practical choice when users or connected systems are in Romania and Central or Eastern Europe. Test application-level latency to the actual audience; a speed test to a nearby endpoint does not replace end-to-end measurements from customer locations.

    5. Workload isolation

    List the services that will share the node. A web application, database, queue, monitoring stack and build runner can interfere with one another even on dedicated hardware. Containers provide process isolation, but they do not create additional CPU, RAM or disk throughput. Reserve limits for non-critical jobs and keep business-critical databases away from noisy batch work.

    6. Recovery objectives

    Decide the maximum acceptable data loss and recovery time before choosing a server. A dedicated node is still a single physical system. Backups should be stored outside the server and restoration should be tested. If the application cannot tolerate the loss of one node, design replication or a multi-node architecture rather than assuming larger hardware creates high availability.

    7. Growth and migration margin

    Size for measured near-term growth, not an undefined five-year forecast. A practical target is enough spare capacity to absorb traffic peaks and the next expected release cycle without paying for hardware that will remain idle. Document the threshold that triggers an upgrade or a second server, such as sustained CPU above 70%, regular swap use or storage exceeding 75%.

    TinyServers dedicated server comparison

    The current range covers three clear capacity levels. Prices and availability can change, so use the linked product pages as the source of truth when ordering.

    Current TinyServers dedicated server plans in Romania
    Plan CPU RAM Storage Good starting point for From
    Ryzen 3 Ryzen 3 3200G, 4C/4T 16 GB DDR4 240 GB SSD Agency sites, small stores, development and private services €54/month
    Ryzen 5 Ryzen 5 5500GT, 6C/12T 32 GB DDR4 512 GB NVMe Container stacks, multiple sites, SaaS applications and databases €69/month
    Ryzen 7 Ryzen 7 5700G, 8C/16T 64 GB DDR4 1 TB NVMe High-traffic applications, larger databases, CI/CD and virtualization labs €89/month

    Do not choose solely by CPU model. For a storage-heavy database, the Ryzen 5 plan with NVMe may be a better operational baseline than the entry SSD plan even when four CPU cores would otherwise be sufficient. For a memory-heavy virtualization lab, the Ryzen 7 plan may be justified by 64 GB RAM before CPU becomes the limiting factor.

    View all dedicated server plans and current availability.

    Example sizing by workload

    Multiple WordPress or e-commerce sites

    Start from measured PHP worker concurrency, database size and cache behavior. The Ryzen 3 plan can suit a modest portfolio with careful caching. Choose Ryzen 5 when several production sites share the node, database activity is heavier or you want NVMe storage and more memory headroom.

    Database or analytics node

    Prioritize RAM and NVMe storage. Confirm the active dataset size, write rate, index growth and backup window. The Ryzen 5 plan is a balanced starting point; Ryzen 7 adds memory and storage for larger datasets. Keep an external backup and do not treat one physical server as a complete high-availability design.

    Game server

    Check single-thread CPU requirements, memory per instance, tick rate and player location. One large instance and several smaller instances have different scheduling behavior. The Bucharest location can reduce latency for Romanian players, but test from the actual player networks before making a final decision.

    Containers and CI/CD runners

    Count concurrent builds and set CPU and memory limits. Build caches and image layers benefit from NVMe, while parallel jobs benefit from more cores and RAM. Separate deployment credentials from build containers and prevent untrusted jobs from reaching host-level sockets.

    Virtualization lab

    Memory is often the first constraint. Add the RAM assigned to guests, reserve capacity for the host, and account for storage growth from snapshots. Ryzen 7 is the natural fit in the current range when multiple virtual machines must run at the same time.

    Pre-order and deployment checklist

    1. Record seven days of CPU, RAM, swap, storage and network measurements from the current environment.
    2. Separate normal usage from peak jobs such as imports, builds, backups and traffic campaigns.
    3. Calculate current data size, monthly growth and temporary space required during backups or upgrades.
    4. Choose SSD or NVMe based on workload latency, not only advertised capacity.
    5. Define off-server backups and perform a test restore.
    6. Document firewall rules, administrator access and key rotation before migration.
    7. Lower DNS TTL before cutover and keep the old environment available during validation.
    8. Set monitoring thresholds that will trigger an upgrade or a second node.
    9. Allow 48–96 hours for dedicated server provisioning after payment confirmation and service review.
    10. If the sizing remains uncertain, contact TinyServers with the workload and measurements before ordering.

    Dedicated server Romania FAQ

    What is a dedicated server?

    A dedicated server is a physical machine assigned to one customer. Its CPU, memory and local storage are not divided into VPS plans for unrelated customers.

    When should I move from a VPS to a dedicated server?

    Move when monitoring shows sustained resource pressure, when you need more RAM or storage than a practical VPS provides, or when physical resource isolation is an operational requirement.

    Why choose a dedicated server in Romania?

    A Romanian location can reduce latency for users and connected systems in Romania and nearby European markets. It also keeps the infrastructure inside the European Union.

    How much RAM should a dedicated server have?

    Use measured peak memory, add the operating system and background services, then keep headroom for growth. TinyServers currently offers dedicated plans with 16 GB, 32 GB and 64 GB RAM.

    Should I choose SSD or NVMe storage?

    SSD is suitable for many entry workloads. Choose NVMe for busy databases, build systems, search indexes and applications sensitive to storage latency.

    How long does dedicated server provisioning take?

    TinyServers normally provisions dedicated servers in 48–96 hours after payment confirmation and service review because each physical server is prepared individually.

    Does a dedicated server include an IPv4 address?

    Yes. Current TinyServers dedicated server plans include one public IPv4 address, root access and an unmetered 1 Gbps network port.

    Next step: compare the current dedicated server plans in Romania, or send your measurements to TinyServers if you need help matching the workload to a server.

  • IPv4 Subnet Sizes and Usable IPs: /8–/32 CIDR Table & Calculator

    IPv4 subnet sizes are determined by the CIDR prefix. A /29 contains 8 total addresses and 6 usable host addresses, a /28 contains 16 and 14, and a /27 contains 32 and 30. Use the complete /8–/32 table or enter any IPv4 CIDR in the calculator to find its subnet mask, network address, broadcast address, and usable range.

    IPv4 subnet size and usable IP address table

    For conventional IPv4 subnets from /8 through /30, usable host addresses equal the total minus the network and broadcast addresses. A /31 is a special point-to-point prefix under RFC 3021, while a /32 identifies one host route.

    IPv4 CIDR reference from /8 to /32
    Prefix Subnet mask Total IPs Usable hosts Typical use
    /8 255.0.0.0 16,777,216 16,777,214 Very large network allocation
    /9 255.128.0.0 8,388,608 8,388,606 Half of a /8 network
    /10 255.192.0.0 4,194,304 4,194,302 Large private or provider block
    /11 255.224.0.0 2,097,152 2,097,150 Very large provider allocation
    /12 255.240.0.0 1,048,576 1,048,574 Private 172.16.0.0 range size
    /13 255.248.0.0 524,288 524,286 Large provider allocation
    /14 255.252.0.0 262,144 262,142 Large provider allocation
    /15 255.254.0.0 131,072 131,070 Two contiguous /16 networks
    /16 255.255.0.0 65,536 65,534 Large private or public network
    /17 255.255.128.0 32,768 32,766 Large enterprise allocation
    /18 255.255.192.0 16,384 16,382 Regional infrastructure allocation
    /19 255.255.224.0 8,192 8,190 Medium infrastructure allocation
    /20 255.255.240.0 4,096 4,094 Small hosting or campus allocation
    /21 255.255.248.0 2,048 2,046 Eight contiguous /24 networks
    /22 255.255.252.0 1,024 1,022 Four contiguous /24 networks
    /23 255.255.254.0 512 510 Two contiguous /24 networks
    /24 255.255.255.0 256 254 Standard small LAN or server network
    /25 255.255.255.128 128 126 Half of a /24 network
    /26 255.255.255.192 64 62 Department or medium service pool
    /27 255.255.255.224 32 30 Larger VPS, proxy, or mail pool
    /28 255.255.255.240 16 14 Small application or customer pool
    /29 255.255.255.248 8 6 Small routed block or service pool
    /30 255.255.255.252 4 2 Traditional point-to-point link
    /31 255.255.255.254 2 2* Point-to-point link (RFC 3021)
    /32 255.255.255.255 1 1* Single host route

    * /31 and /32 are special routing cases rather than conventional multi-host subnets. On a /31 point-to-point link both endpoint addresses are usable; a /32 represents exactly one address.

    IPv4 CIDR subnet calculator

    Enter an IPv4 address with its prefix, such as 192.0.2.40/29. The calculator runs in your browser and does not send the address anywhere.

    The table uses the standard host count: total addresses minus network and broadcast for /8–/30. In an on-link configuration, a router may consume one of those usable host addresses as the gateway. A routed block avoids that extra allocation because the next hop is the VPS main IP outside the block. TinyServers therefore makes all 6 host addresses in a routed /29, all 14 in a /28, and all 30 in a /27 available for configuration on the server.

    /32 subnet: 1 IP address

    A /32 uses mask 255.255.255.255 and identifies one exact IPv4 address. It is normally used as a host route, loopback, or routed service address.

    /31 subnet: 2 endpoint addresses

    A /31 uses mask 255.255.255.254. RFC 3021 permits both addresses on a point-to-point link, where separate network and broadcast addresses are unnecessary.

    /30 subnet: 4 total, 2 usable IPs

    A /30 subnet mask is 255.255.255.252. It has 4 total addresses and 2 usable host addresses, which made /30 the traditional choice for point-to-point links.

    /29 subnet: 8 total, 6 usable IPs

    A /29 subnet mask is 255.255.255.248. It provides 8 total addresses and 6 usable host addresses. For a small pool attached to a VPS, see the TinyServers routed /29 IPv4 add-on.

    /28 subnet: 16 total, 14 usable IPs

    A /28 subnet mask is 255.255.255.240. It provides 16 total addresses and 14 usable host addresses. The routed /28 IPv4 add-on suits larger service, VM, or customer pools.

    /27 subnet: 32 total, 30 usable IPs

    A /27 subnet mask is 255.255.255.224. It provides 32 total addresses and 30 usable host addresses. For a larger VPS address pool, see the TinyServers routed /27 IPv4 add-on.

    /26 subnet: 64 total, 62 usable IPs

    A /26 uses mask 255.255.255.192 and divides a /24 into four equal blocks. Each block has 64 total addresses and 62 conventional host addresses.

    /25 subnet: 128 total, 126 usable IPs

    A /25 uses mask 255.255.255.128 and divides a /24 into two halves. Each half contains 128 total addresses and 126 usable host addresses.

    /24 subnet: 256 total, 254 usable IPs

    A /24 uses mask 255.255.255.0. It is the familiar 256-address block with 254 conventional host addresses.

    /23 subnet: 512 total, 510 usable IPs

    A /23 uses mask 255.255.254.0 and combines two contiguous /24 blocks, giving 512 total addresses and 510 usable hosts.

    /22 subnet: 1,024 total, 1,022 usable IPs

    A /22 uses mask 255.255.252.0 and combines four contiguous /24 blocks.

    /21 subnet: 2,048 total, 2,046 usable IPs

    A /21 uses mask 255.255.248.0 and combines eight contiguous /24 blocks.

    /20 subnet: 4,096 total, 4,094 usable IPs

    A /20 uses mask 255.255.240.0 and is often large enough for a campus or hosting allocation.

    /19 subnet: 8,192 total, 8,190 usable IPs

    A /19 uses mask 255.255.224.0 and contains thirty-two /24-sized blocks.

    /18 subnet: 16,384 total, 16,382 usable IPs

    A /18 uses mask 255.255.192.0 and contains sixty-four /24-sized blocks.

    /17 subnet: 32,768 total, 32,766 usable IPs

    A /17 uses mask 255.255.128.0 and represents half of a /16 network.

    /16 subnet: 65,536 total, 65,534 usable IPs

    A /16 uses mask 255.255.0.0 and is common as a large private or enterprise network boundary.

    /15 subnet: 131,072 total, 131,070 usable IPs

    A /15 uses mask 255.254.0.0 and combines two contiguous /16 networks.

    /14 subnet: 262,144 total, 262,142 usable IPs

    A /14 uses mask 255.252.0.0 and combines four contiguous /16 networks.

    /13 subnet: 524,288 total, 524,286 usable IPs

    A /13 uses mask 255.248.0.0 and combines eight contiguous /16 networks.

    /12 subnet: 1,048,576 total, 1,048,574 usable IPs

    A /12 uses mask 255.240.0.0. The private 172.16.0.0–172.31.255.255 range is one familiar /12-sized block.

    /11 subnet: 2,097,152 total, 2,097,150 usable IPs

    A /11 uses mask 255.224.0.0 and combines thirty-two contiguous /16 networks.

    /10 subnet: 4,194,304 total, 4,194,302 usable IPs

    A /10 uses mask 255.192.0.0 and represents one quarter of a /8 network.

    /9 subnet: 8,388,608 total, 8,388,606 usable IPs

    A /9 uses mask 255.128.0.0 and represents half of a /8 network.

    /8 subnet: 16,777,216 total, 16,777,214 usable IPs

    A /8 uses mask 255.0.0.0. It is a very large block containing 256 contiguous /16 networks.

    Which routed IPv4 subnet size should you choose?

    • /29 — 6 usable IPs: a few services, mail endpoints, or a small multi-tenant setup.
    • /28 — 14 usable IPs: agencies, VM labs, or medium customer and application pools.
    • /27 — 30 usable IPs: larger mail, virtualization, proxy, or VPN infrastructure.

    Compare ordering and configuration examples in Routed IPv4 subnets for VPS: /29 vs /28 vs /27, browse all routed IPv4 add-ons, or start with an NVMe VPS plan.

    IPv4 subnet FAQ

    How many IPs are in a /28 subnet?

    A /28 has 16 total IPv4 addresses and 14 usable host addresses. Its subnet mask is 255.255.255.240.

    What is a /29 subnet mask and how many IPs does it have?

    A /29 uses subnet mask 255.255.255.248. It contains 8 total addresses and 6 usable host addresses.

    How many usable IPs are in a /30?

    A /30 has 4 total addresses and 2 usable host addresses. Its subnet mask is 255.255.255.252.

    How many IPs are in a /27 subnet?

    A /27 has 32 total addresses and 30 usable host addresses. Its subnet mask is 255.255.255.224.

    Why are two addresses unavailable in a normal IPv4 subnet?

    The first address identifies the network and the last is the broadcast address. The /31 and /32 prefixes are special exceptions used for point-to-point links and host routes.

    Does a routed subnet lose another address to a gateway?

    No. When the subnet is routed through a VPS main IP outside the block, no host address inside the block must be assigned as its gateway.

  • How to Reinstall the OS on Your VPS in Minutes (Self-Service)

    My Virtual Machines panel in the TinyServers control panel with the Reinstall OS button

    Reinstalling the operating system on a VPS used to mean opening a support ticket, waiting for a technician and hoping your IP address did not change. On TinyServers, OS reinstallation is now self-service: you pick a new operating system in the client panel and the VPS is redeployed in minutes — same plan, same price, same IPv4 address.

    This guide shows how the Reinstall OS feature works, what happens behind the scenes, and when a clean reinstall is the right move.

    How to reinstall the OS on your VPS

    1. Log in to your TinyServers account and open the My Virtual Machines tab.
    2. Find your VPS in the list and click Reinstall OS.
    3. Choose the operating system you want from the catalog: Debian 13, Ubuntu 24.04 LTS, Rocky Linux 9 or AlmaLinux 9.
    4. Confirm. The panel shows the reinstall progress live — no ticket, no waiting on support.

    A few minutes later the VPS is back online with a fresh operating system, a new root SSH key and the same IPv4 address as before.

    What happens behind the scenes

    The reinstall is built to be safe by default:

    • Automatic backup first. A backup of your current system is taken before the old installation is removed, so your data is not lost the moment you click the button.
    • Validated switchover. The new system is cloned and verified on the network before the old one is destroyed. If anything fails, the reinstall rolls back and your original VPS keeps running.
    • Same IP address. Your IPv4 stays reserved for your VPS, so DNS records, firewall rules and client configurations keep working.
    • Same plan resources. CPU, RAM and NVMe disk stay exactly as defined by your plan — only the operating system changes.
    • Fresh SSH access. A new root SSH key is generated for the new installation and available in the panel.

    When a clean reinstall is the right move

    • Switching distributions — you started on Ubuntu but your stack is better supported on Debian or a RHEL-compatible system like Rocky or Alma.
    • A broken system — failed upgrades, broken package managers or misconfigured boot setups are often faster to reinstall than to repair.
    • A suspected compromise — after a security incident, a clean OS image is the only base you can fully trust.
    • Starting a new project — reuse an existing VPS for something new without leftover packages, users and configs.
    • Learning and testing — break things on purpose, then reset to a clean system in minutes. This pairs well with a low-cost 1 GB VPS used for testing.

    Before you click Reinstall: a 3-step checklist

    1. Copy off anything you still need. The automatic pre-reinstall backup is a safety net, not an archive strategy. Download databases, configs and uploads you care about.
    2. Note your stack. A quick list of installed services (web server, PHP version, cron jobs) makes rebuilding much faster.
    3. Keep your DNS as is. Because the IP address does not change, you do not need to touch DNS records — the same domain will point at the fresh system.

    Which operating system should you choose?

    • Debian 13 — stable, lightweight, great default for most servers and small VPS plans.
    • Ubuntu 24.04 LTS — the widest tutorial and package ecosystem, five years of support.
    • Rocky Linux 9 / AlmaLinux 9 — RHEL-compatible, ideal for cPanel-style panels and enterprise-flavored stacks.

    If you are unsure, start with Debian or Ubuntu — and remember you can switch later with a few clicks. That is the whole point.

    Quick FAQ

    Does reinstalling the OS change my IP address?

    No. Your VPS keeps the same IPv4 address after the reinstall, so DNS records and firewall rules keep working.

    Is my data deleted when I reinstall?

    The disk is replaced with a fresh OS image, but an automatic backup is taken before the old system is removed. You should still download anything important first.

    How long does a reinstall take?

    Typically a few minutes. The panel shows live progress, and the old system keeps running until the new one is validated.

    Does it cost anything?

    No. Self-service OS reinstallation is included with every TinyServers VPS plan, from the 1 GB NVMe VPS at €2.48/mo up.

    Get a VPS with self-service OS reinstall

    Every TinyServers NVMe VPS includes the Reinstall OS feature, free backup, IPv4 and full root access, hosted in Romania on 1 Gbps networking.

    Related reading: free VPS backups from the panel and the TinyServers control panel.

    Next step: self-service OS reinstall is included with every plan — pick an NVMe VPS Romania plan from €2.48/month.

  • Routed IPv4 Subnets for VPS: /29 vs /28 vs /27

    Most VPS users get one IPv4 address with their plan and never think about it again. But the moment you start hosting multiple SSL sites without SNI, running a mail server with proper per-domain reputation, building a small VPN provider, or separating tenants on a single box, that single IP becomes a hard wall. This guide explains when you actually need extra IPv4, how to choose between a single address and a routed /29, /28 or /27 subnet, and how to order and configure one on a TinyServers NVMe VPS.

    Why one IPv4 is sometimes not enough

    Here are the real-world scenarios where customers reach out for additional addresses:

    • Mail server with multiple domains. SMTP reputation is tied to the sending IP. Mixing transactional and marketing mail on a single address means one bad campaign can poison delivery for everything else. A small subnet lets you bind each domain or each traffic class to its own IP and PTR record.
    • Multiple SSL sites for legacy clients. SNI covers the modern web, but if you have to support old TLS clients, IoT devices, or some payment gateways, every certificate still needs its own IPv4.
    • VPN exit nodes. WireGuard and OpenVPN endpoints, especially commercial or per-user exits, benefit from distinct public IPs to avoid CGNAT-like blacklisting and to give each tenant a clean address.
    • Multi-tenant hosting and reverse proxies. Agencies running many small sites on one VPS often want to give each customer a dedicated public IP for billing, isolation, or to allow customers to point their own DNS without coordinating.
    • Outbound proxy or scraping pools. Rotating across a /28 or /27 spreads request volume and reduces rate-limit collisions.
    • NAT and lab segmentation. Routed subnets give you a clean L3 block to NAT internal containers or LXC guests behind, with no bridging tricks.

    If none of those describe you, a single extra IPv4 at €1.00/month is almost always the right starting point. If two or more apply, a routed subnet is cheaper per address and far easier to manage long-term.

    Single IPv4 vs routed subnet — what changes

    A single extra IPv4 is added to your existing VPS interface as an alias. From the OS side it looks like:

    ip addr add 203.0.113.45/32 dev eth0

    It works for SMTP, extra HTTPS vhosts, or a second VPN endpoint, but it is not a network you can subdivide.

    A routed subnet is different. The provider routes the entire block (a /29, /28, or /27) to your VPS as the next hop. You receive the subnet on a separate interface or as additional addresses, and you control the inside however you want — bind addresses to services, assign them to LXC/Docker containers, NAT internal networks behind them, or build a small lab network. There is no MAC-layer dependency, no bridging, no provider ARP magic. The traffic for any address in the block lands on your VPS because the upstream routes it there.

    The practical implication: a routed subnet behaves like a real network you own, not like a list of aliases. That is exactly what you need for containers, NAT, or per-tenant isolation.

    The decision table: /29 vs /28 vs /27

    All three TinyServers routed subnets are billed monthly with no setup fee. Here is how they compare on cost-per-usable-IP:

    ProductMonthly priceUsable IPsCost per IPBest fit
    Routed /29€8.906€1.48Entry subnet — small NAT, light multi-tenant, per-domain mail
    Routed /28€14.9014€1.06Agencies, mid-size multi-tenant layouts, mixed VPN+web
    Routed /27€26.9030€0.90Validated use case where /28 is too tight — proxy pools, larger VPN providers

    Three rules of thumb:

    1. Start with /29 unless you have a written list of 6+ addresses you will use in month one. Most customers who jump straight to /28 underuse it for the first quarter.
    2. If you are between /28 and /27, take the /28 and grow. Upgrading later is straightforward; over-provisioning IPv4 is expensive and increasingly frowned upon by RIRs.
    3. If you genuinely need /26 or larger, contact us directly. Anything above /27 is reviewed case-by-case and is not orderable from the cart.

    Configuring a routed /29 on a Linux VPS

    Once the subnet is provisioned, you will receive the block (for example 203.0.113.40/29) and the gateway your VPS already uses. There is no separate gateway for the routed block — your VPS itself is the gateway for that subnet.

    The fastest, distribution-agnostic way to bring addresses up is the ip command — it works identically on Debian, Ubuntu, Rocky and Alma:

    # add the addresses you want to use
ip addr add 203.0.113.41/29 dev eth0
ip addr add 203.0.113.42/29 dev eth0
ip addr add 203.0.113.43/29 dev eth0

    You only need to add the addresses you actually plan to bind to services — the rest of the block is still routed to your VPS and you can add them later without downtime.

    These commands are not persistent across reboots. To make the configuration survive a restart, write it into the network manager your distribution uses by default:

    • Ubuntu 24.04 — add the extra addresses under ethernets.eth0.addresses in /etc/netplan/*.yaml, then run netplan apply.
    • Debian 12 — add an up ip addr add ... line for each address under the iface eth0 stanza in /etc/network/interfaces.
    • Rocky 9 / Alma 9 — use nmcli connection modify <conn> +ipv4.addresses 203.0.113.41/29 (repeat per address), then nmcli connection up <conn>.

    In all cases the addresses behave the same once they are up — the choice is purely about how your distribution stores network state.

    Quick sanity test from another machine:

    for ip in 41 42 43; do ping -c1 -W1 203.0.113.$ip; done

    Bind a service to a specific IP — for example, an extra Nginx vhost:

    server {
    listen 203.0.113.42:443 ssl;
    server_name client-a.example.com;
    ssl_certificate     /etc/letsencrypt/live/client-a.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/client-a.example.com/privkey.pem;
    # ...
}

    Per-IP rDNS is available on request — open a ticket with the IP and the desired PTR. This is essential for mail servers; without correct PTR, most receivers will defer or reject your messages.

    Three real customer patterns

    1. Small mail host on a 4 GB VPS

    A consultancy hosts mail for six client domains on TSM4NVME40. They added a /29 and assigned one IP per domain, with matching PTR records. Result: deliverability issues from one client’s newsletter no longer affect the other five. Total cost: €5.46 + €8.90 = €14.36/month for six independently reputable mail IPs.

    2. Agency hosting 12 small WordPress sites

    A web agency runs a dozen low-traffic sites on a single 2 GB VPS. They took a /28 so each customer gets a dedicated public IP — useful for legacy DNS setups customers manage themselves and for billing transparency. Cost per customer for the IP: roughly €1/month, baked into the hosting fee.

    3. WireGuard VPN provider, beta phase

    A small VPN startup runs WireGuard on a 4 vCPU VPS and rotates exits across a /28. When they outgrew it (week three), they upgraded to a /27. Lesson learned: they should have started with a /29 to validate the model and then jumped to /27 directly.

    What we do not allow

    Routed subnets are reviewed manually before allocation. Use cases that will be rejected:

    • Bulk unsolicited email or anything resembling cold-mail at scale
    • Open proxies or open resolvers exposed to the public internet
    • Address hoarding — ordering a /27 with no concrete plan to use the IPs
    • Reselling individual IPv4 addresses as a standalone product

    If your project is sensitive to abuse complaints (large-scale crawling, marketing email, anonymization services), tell us upfront. We would rather have an honest conversation than reclaim addresses later.

    How to order

    1. Make sure you have an active TinyServers VPS. Routed subnets are not standalone products — they require a VPS as the routing target.
    2. Open the IPv4 add-ons category and add the subnet size you need to your cart.
    3. Complete the order. The first allocation requires manual review. Once approved, we will email you the block, confirm the gateway your VPS already uses, and handle any rDNS requests you send in.
    4. Configure the block on your VPS using the ip commands above (and the persistent equivalent for your distribution) and start binding services.

    If you are unsure which size fits, the safe answer is almost always start with /29. The €6 difference per month between /29 and /28 is much smaller than the cost of unused address space sitting idle for six months.

    FAQ

    How many usable IPs do I get in a /29, /28 or /27?

    A routed /29 gives you 6 usable IPv4 addresses, a /28 gives 14 and a /27 gives 30. Two addresses per block are reserved for network and broadcast — and because the whole block is routed to your VPS, no extra address is lost to a gateway, unlike on-link allocations. Full reference: subnet size table & calculator (/30 to /24).

    Can I upgrade from /29 to /28 later?

    Yes. The new block is routed alongside the old one — you keep using the /29 addresses while you migrate services, then we deprovision the smaller block when you are ready. No forced renumbering.

    Do I get the addresses immediately?

    Provisioning is manual to keep abuse rates low. Once your order is approved, the block is routed within minutes and you can configure it on your VPS.

    Do I need a TinyServers VPS to order?

    Yes. Routed subnets are add-ons for existing VPS plans — they have to terminate somewhere, and we route them to a VPS in your account. If you do not have one yet, start with a small NVMe plan from €2.48/month and add the subnet on top.

    Can I use the addresses on a non-TinyServers server?

    No. Routed blocks are tied to a TinyServers VPS as the next hop. We cannot announce them to a third-party network from the storefront product — that requires a separate BGP arrangement.

    What about /26 or larger?

    Available, but not from the cart. Contact us with your use case and projected utilization timeline.

    Summary

    Extra IPv4 is one of those line items that looks small but quietly unblocks entire classes of projects — proper mail hosting, multi-tenant agency setups, VPN services, container labs. If you only need one or two extra addresses, the single IPv4 add-on is the right call. If you need a real network you can subdivide, start with a /29, grow into a /28, and only step up to a /27 once you have validated the use case.

    Pair any of them with one of our NVMe VPS plans in Romania and you have a clean, low-cost foundation for projects that have outgrown a single public IP.

    Next step: order IPv4 add-ons for VPS only for active TinyServers VPS services, or start with an NVMe VPS Romania plan.

  • WordPress VPS Romania: Setup, Sizing, and Performance Checklist

    WordPress VPS Romania: Setup, Sizing, and Performance Checklist

    Running WordPress on a VPS gives you control, but sizing and tuning mistakes can quickly hurt speed and uptime. This guide covers a practical setup baseline for Romania-hosted NVMe VPS instances.

    Recommended starting point

    For most production WordPress sites, start at 2 GB RAM with NVMe storage. This leaves headroom for plugins, caching, updates, and traffic bursts.

    Secure baseline stack

    • Nginx + PHP-FPM with conservative worker settings.
    • MariaDB tuned for realistic memory limits.
    • TLS via certbot and strict firewall rules.
    • Backups and restore testing, not backups only.

    Performance checklist

    • Enable page/object caching where appropriate.
    • Audit plugins and remove non-essential add-ons.
    • Track RAM usage and swap behavior after plugin updates.
    • Run regular DB optimization and slow query checks.

    When to scale up

    • Admin panel feels slow during normal activity.
    • RAM stays high during routine traffic.
    • Background jobs compete with front-end response time.

    If these persist after tuning, move to 4 GB and re-test.

    Upgrade options

    Related articles

    FAQ

    Is 1 GB enough for WordPress?

    Only for very light sites. For most production use cases, 2 GB is more reliable.

    How often should I review performance?

    Weekly for active websites and after every major plugin or theme change.

    What matters most for WordPress speed?

    Balanced RAM headroom, NVMe storage, clean plugin set, and cache discipline.

    Related buying guides

    Next step: compare the current NVMe VPS Romania plans, including 1 GB VPS, 2 GB VPS and 4 GB VPS options.

  • Migrate a 20i VPS to TinyServers: Zero-Downtime Checklist

    Migrate a 20i VPS to TinyServers: Zero-Downtime Checklist

    This runbook moves a Linux web workload from a 20i VPS to a TinyServers NVMe VPS while keeping the old server available during DNS propagation. It uses an initial copy, pre-cutover testing and a final data sync. “Zero downtime” still depends on the application: write-heavy systems should use maintenance mode or database replication during the final cutover.

    (more…)

  • Install WordPress on an NVMe VPS: 7-Step Debian Guide

    Install WordPress on an NVMe VPS: 7-Step Debian Guide

    This command-by-command guide deploys a lean WordPress site on the TSM1NVME10 plan (1 vCPU, 1 GB RAM, 10 GB NVMe; current plans from €2.48/month). Use 1 GB for a small cached site or test environment; choose the 2 GB plan for a public, plugin-heavy or business-critical site.

    (more…)