Servers & Cloud
Every cloud server in one place — measured properly, priced in full.
Hetzner, DigitalOcean, TransIP and OVHcloud in one list, with the whole lifecycle behind it: create, power, rebuild, rescue, a web console, backups, snapshots, volumes, private networks and load balancers. A one-minute agent adds the numbers no cloud API has — memory, disk space, load average, and an alert when a machine goes quiet. And the cost panel adds up what each server is actually billed for, not just what its plan costs.
Free plan · No credit card · Connect a provider in 2 minutes
- Every cloud you connect, in one server list, with search and filters
- Memory, disk space and load your cloud API cannot report
- What each server costs once its volumes and IPs are counted
- Alerts that wait for a sustained problem, not a one-second spike
- Two delete locks, and a delete that says what it deletes
14 servers · 12 running
Point-in-time copies of your server disks, kept even after a server is deleted.
Floating IP addresses you can attach to and move between your servers.
5 servers are polled by their provider, so memory, disk space and load are not being measured on them.
14 servers across 4 accounts · €425.59/mo
6 snapshots · 71.3 GB stored
3 attached to nothing — €6.30 a month
A reserved address keeps billing after the server it was reserved for is gone. Release it at your provider, or attach it to a server.
14 addresses across 4 accounts
Works with your clouds
Your cloud knows how busy a server is. It cannot know how full the disk is.
Every cloud API will tell you about CPU and network, every five minutes, and InfraNest graphs that the moment you connect an account — nothing to install. What no cloud API will tell you is how much memory is left, how full the disk is, or what the load average has been doing, because those numbers only exist on the machine. That is not a gap in the integration; it is a fact about the interface. So the second tier is an agent — one command, about a minute, the same command on every server — and it brings a reading a minute, the processes eating the box, the largest folders on the mount that is filling, the services that failed and why, and the one alert polling structurally cannot do: this server has stopped reporting. Until it is installed, a rule on memory or disk is greyed out rather than accepted, because a rule you can save and that can never fire is worse than a control you cannot reach.
- CPU, network and disk throughput from your provider with nothing installed, on every cloud that has a metrics API
- Memory, disk space, load average and uptime once the agent is on — measured on the machine, once a minute
- “What is filling the disk” is a list of folders, so “94% full” arrives with something to delete
- Failed services explain themselves in words: ran out of memory, took too long, failed too often to keep retrying
- Rules on agent-only metrics stay greyed out until the agent is there, rather than saving a rule that could never fire
api-02
cpx41 · Falkenstein · a reading every 5 minutes
CPU
46%
of 8 vCPU
Memory
needs the agent
Disk
needs the agent
Load average
needs the agent
Memory, disk space and load need the agent — a cloud API cannot report them.
api-01
cpx41 · Falkenstein · a reading every minute
CPU
50%
of 8 vCPU
Memory
62%
of 16 GB
Disk
44%
on /
Load average
4.03
8 cores
What the agent adds
- An alert when the server stops reporting at all — the one thing polling structurally cannot notice.
- The processes using the most CPU and memory, sampled on the machine itself.
- What is filling the disk — the largest folders on the fullest mount, so “94% full” arrives with something to delete.
- The services the machine was told to run, and in plain language why any of them failed.
One command, about a minute — and the same command on every server, whichever cloud it is on.
What a server actually costs, once you count what is attached to it
A plan price is not a bill. The machine in the panel opposite is a €15.90 server carrying a €12.00 volume and its own €0.60 IPv4, so the number people quote for it is 56% of what it takes off the card each month. The cost panel adds up everything billed to that machine — the server, its backups, each volume, IP address and snapshot attached to it, plus anything you add yourself, like a licence or a support contract the provider knows nothing about. The IP line matters more than it sounds: with most providers a public IPv4 is billed separately, so leaving it out makes every server in your estate look slightly cheaper than it is. Nothing is double-counted — a volume shown here is the same volume counted once in the Spend report, not an extra charge on top. And the other tab is the part nobody has a page for: the volumes and reserved addresses attached to nothing, which are billed in full every month and appear on no server, because they are on no server.
- Server, backups, volumes, IP addresses and snapshots, plus your own manual cost lines
- Priced in the currency your provider quotes, net of VAT, and labelled an estimate — the invoice is the final word
- Counted once: an attached volume here is the same volume in the organisation Spend report, never a second charge
- Unattached volumes and reserved IPs are totalled, because a thing that is on no server is on no server’s page
- InfraNest will not release them for you: it can see that an address is unattached, not whether you are holding it for a move
Cost
web-01 · cpx31
- Monthly (base)from provider
- €15.90
- Volumeuploads
- + €12.00
- IP address5.75.140.10
- + €0.60
- Estimated total
- €28.50/mo
The plan is €15.90. The machine is €28.50 — the plan is 56% of what it costs you.
Estimate based on the data we have — including backups and any volumes, IP addresses and snapshots attached to this server. Your actual invoice may differ.
Prices are stored and shown excl. VAT.
Attached to nothing2 volumes · 3 reserved addresses
€60.30/mo
A detached volume keeps your data and keeps its price; a reserved address keeps costing whether or not it points anywhere. None of this is on a server’s page, because none of it is on a server — which is exactly why it goes unnoticed. InfraNest counts it, totals it, and names the machine each one used to belong to. It deliberately will not release any of it for you: we can see that something is unattached, not whether you are holding it for a move.
A standing check on every server, and what it finds today
Nobody audits a server they are not currently worried about, which is why the things that bite you are the ones that were fine when you last looked. So every server carries a standing check — eleven of them — sitting on the page you were going to open anyway: is there a firewall at all, is SSH open to the world, is a database port reachable, is there a restore point, is delete protection on, is anything watching it, has it been up long enough to be missing kernel patches, are there volumes being billed for nothing. Each finding says what is true now rather than what the goal is, explains itself in a sentence, and carries the button that fixes it. What it will not do is tell you something is fine because it did not look: on a cloud with no firewall API, the four firewall checks are absent rather than quietly green — which is a distinction a security panel has to make, and the one its own test exists to protect.
- Eleven checks per server, sorted so a critical is never below a suggestion
- Each finding carries its fix — attach a firewall, take a snapshot, turn on monitoring, enable delete protection
- A check the provider cannot answer is not shown, rather than reported as passed
- Not on a private network is information, not a warning — it is a trade, and staying off is a normal choice
- Dismiss a finding per check, so a deliberate exposure stops nagging without switching the advisor off
Hetzner · cax21 · Falkenstein
FirewallNo firewall attached
Fix in firewallA firewall lets you expose only the ports you actually use. Without one, every port on this server is reachable from the internet.
SnapshotNo snapshot taken
Create snapshotA snapshot is a quick, manual restore point — handy to take right before risky changes like an OS upgrade.
ProtectionDelete protection is off
Enable delete protectionDelete protection prevents the server from being destroyed in a single click. Turn it on for production servers.
MonitoringNo monitoring configured
Add monitoringMonitoring and alert rules notify you of downtime or resource problems before your users do.
UptimeRunning for over 90 days
A server running for over 90 days is likely missing kernel and OS security patches that only take effect after a reboot.
NetworkNot on a private network
Open networkingA private network carries server-to-server traffic (databases, app tiers) without going over the public internet. It is a trade, not an upgrade: every server on the network can reach every port the others expose on their private address, and this provider’s cloud firewall rules do not apply to that traffic. Attach one when these servers need to talk to each other — staying off is a normal choice.
VolumesUnattached volumes are being billed
Review volumesYour organisation has unattached volumes that are still billed. Attach the ones you need and delete the rest.
✓ Show 4 passed
Hetzner · ccx23 · Helsinki
NetworkNot on a private network
Open networkingA private network carries server-to-server traffic (databases, app tiers) without going over the public internet. It is a trade, not an upgrade: every server on the network can reach every port the others expose on their private address, and this provider’s cloud firewall rules do not apply to that traffic. Attach one when these servers need to talk to each other — staying off is a normal choice.
VolumesUnattached volumes are being billed
Review volumesYour organisation has unattached volumes that are still billed. Attach the ones you need and delete the rest.
✓ Show 9 passed
Restore points, and a way back into a server that locks you out
Two questions decide whether a bad afternoon is an incident or an inconvenience: can I undo this, and can I still get in? Provider backups run on a schedule and restore in a click. Snapshots are the ones you take yourself, thirty seconds before the risky thing — and because a snapshot is stored compressed, an 80 GB disk usually costs you about six. Kept snapshots are still money, so the list prices them on what they actually occupy and feeds the Spend report, which is where snapshot sprawl stops being a hunch. And when the machine will not let you in at all — SSH refusing, a boot that never finishes, a firewall rule you closed behind yourself — there is a live console in the browser: a screen and a keyboard attached straight to the machine, with temporary credentials that expire and an audit-log line saying who opened it.
- Provider backups: switch on, trigger one now, restore, delete — where the cloud offers them
- Snapshots you take yourself: create, restore, rename, protect from deletion, delete
- Priced on the compressed image rather than the disk, so the figure is what you are actually billed
- A live VNC console for a machine that will not accept SSH, with credentials that expire shortly after
- Bring your own client instead — the panel hands you the WebSocket URL, or VNC host, port and password
Manual point-in-time copies you take yourself.
6 snapshots, 3 protected from deletion — 375 GB of disk stored as 71.3 GB, 81% smaller.
A snapshot is priced on what it actually occupies, not on the size of the disk it came from — automatically where your provider publishes a rate, and set by you where it does not. It feeds the Spend report, which is where snapshot sprawl stops being a hunch and becomes a number.
For when SSH refuses, the server will not finish booting, or a firewall rule shut you out.
Credentials are temporary, requested per session and expiring shortly after. Opening one is written to the audit log, so the team can see who connected and when.
Server alerts that average a window, not ones that catch a spike
The reason people mute infrastructure alerts is that the alerts are usually wrong, and the usual cause is a threshold compared against one reading. “CPU above 85% for 15 minutes” ought to mean the average across those fifteen minutes, and here it does: every reading in the window is averaged and the average is what the rule compares, so a one-minute backup spike wakes nobody and a Saturday afternoon of real load wakes somebody. Recovery gets a margin as well — the average has to come back a clear 10% under the threshold before anything is called recovered, so a value sitting exactly on the line cannot alert and recover all night. You get at most two messages per alert: it fired, and it is back. And if a spike was too short to fire, you hear nothing at all, not even an all-clear for an alert that never happened.
- Set a rule once for the organisation; every server inherits it, any server can override it, and a reset drops back to the org rule
- The duration is an averaging window, not a stopwatch — two spot readings fifteen minutes apart are not a breach
- A window that does not hold enough readings returns no verdict at all, which is deliberately not the same as “fine”
- A breach opens a real incident alongside your uptime incidents, and closes itself when it clears
- A server that has never reported is treated as “nobody installed the agent yet”, not as a silent machine
Alert rules
Get notified when a metric stays above or below a threshold.
Inherited by 11 servers. Set for the whole organisation. Change it here to override it for this server only.
Those 15 minutes are an averaging window, not a stopwatch
Every reading in the window is averaged, and the average is what the rule compares. A minute above the line is not a breach; a window above it is.
A backup pins a core for a minute
peak 98%average 25.4%
Nobody is woken
Load arrives, and stays
peak 95%average 89.7%
Alerts
Recovery needs a margin too. A rule at 85% is not called recovered until the average is back under 76.5% — 10% below the line — so a value sitting on the threshold cannot alert and recover all night. Two messages per alert at most: it fired, and it is back. A spike too short to fire sends nothing at all, not even an all-clear for an alert that never happened.
Two things a threshold cannot express
No data from the agent
A provider API keeps answering cheerfully about a machine that is wedged, and an attacker who owns the box turns the agent off. Absence is the signal — which makes this an operational alert and a security one at once. A server that has never reported is treated as “nobody installed it yet”, not as silence.
A watched service has failed
Explained in words rather than in systemd: ran out of memory, took too long and was stopped, failed too often to keep retrying, could not get what it needed to start. Enough to know whether to look at the machine’s size or at its configuration.
A month of your servers, with the caveats attached to the rows
CPU, memory and disk for the whole fleet over a month you choose, with peak and average side by side — because a steady 60% and one bad afternoon can have the same average, and only one of them is a reason to resize. Amber above 75%, red above 90%. What makes the table usable rather than merely present is that every row says how much of the month it is based on: a server measured on twelve days of thirty-one is not comparable to one measured on all of them, and a server added mid-month says so, so a short measurement reads as a new server rather than a monitoring failure. A server with no readings says “No readings”, never zero — we will not tell you a machine used no CPU when what we mean is that we did not hear from it. Where a disk is filling on a steady trend you get “full in about nine days”, and only for a period that includes today, so a live forecast is never pinned to last August.
- Peak and average together for CPU, memory and disk, with a sparkline of the month’s shape
- Amber above 75%, red above 90% — tinted rather than merely recoloured, so a number in trouble is readable at a glance
- “12 of 31 days” on every row, and a warning tint when the month is thin enough to read low
- No readings is “No readings”, never a zero — the two mean opposite things
- Disk forecasts only for a period that includes today, because a trend describes now and not last summer
September 2026 · month still running
| Server | CPU peak | Memory peak | Disk peak | Measured |
|---|---|---|---|---|
| queue-01 | 83.4%avg 57.2% | 80.5%avg 74.2% | 56.4%avg 55.7% | 2 of 30 days |
| api-01 | 65.4%avg 45.0% | 74.6%avg 68.3% | 45.4%avg 44.7% | 2 of 30 days |
| db-01 | 42.7%avg 32.5% | 68.3%avg 62.0% | 78.4%avg 77.7% | 2 of 30 days |
| api-02 | 60.2%avg 41.3% | 2 of 30 days | ||
| web-02 | 29.0%avg 17.3% | 61.6%avg 55.3% | 30.4%avg 29.7% | 2 of 30 days |
| analytics-01 | No readings |
No server ran short of CPU, memory or disk.
6 of 14 servers shown — one for each state the report can be in.
Private networks: every server on one can reach every other
This is the part most consoles leave you to discover. Every server on a private network can reach every port every other server exposes on its private address, and there is no allow step in between — joining the network is the permission. On Hetzner the cloud firewall cannot filter that traffic at all, because its rules apply to the public interface, so who is attached is the only control there is. DigitalOcean is different: its firewalls do filter VPC traffic. InfraNest does not guess which of those you are dealing with. Before you confirm an attach it names what becomes reachable and says whether the firewall applies, read from a capability the provider declared rather than from an assumption about how clouds work. It also does not treat staying off a private network as a problem to fix: a CI runner, or a public site with nothing to share, has no reason to join one. We removed a banner that suggested otherwise, because we hold no traffic data and it was an opinion rather than a measurement.
- Create a network, add subnets, and attach servers from either side — the network or the server
- Before an attach is confirmed, what becomes reachable is named and the firewall question is answered
- Whether the cloud firewall reaches private traffic is read from a declared capability, per provider, not assumed
- A plain-English summary of the network: its zone, how many servers share private IPs, and whether any routes exist
- Not joining is a legitimate answer, and InfraNest does not nag about it
6
servers
2
subnets
0
routes
In plain English
private-backbone is a private network in eu-central. 6 servers are connected over private IPs. No routes — traffic stays inside 10.0.0.0/16.
What attaching a server grants
6 servers are on this network today, and every one of them becomes reachable from the new one on its private address — on every port it exposes there. There is no allow step in between.
Staying off a private network is not treated as a problem to fix. A CI runner, or a public site with nothing to share, has no reason to join one. We removed a banner that suggested otherwise: we hold no traffic data, so it was an opinion rather than a measurement.
No server gets deleted by accident — and “remove” means two different things
Delete destroys the machine at your provider and the billing stops. Stop tracking leaves it running, leaves it billing, and simply takes it out of InfraNest. Those are not variations on one action, and the confirmation says which one you are about to do — including, on a provider where deleting is really a cancellation, whether the machine goes now or at the end of a period you have already paid for. Stop tracking is fully reversible and asks for no re-authentication, deliberately: putting a gate on the reversible button pushes people towards the one that is not. Deleting asks for the server’s name and your organisation’s re-authentication where it is required, and the capability check runs first, so you are never asked for a passkey for an action the provider was never going to allow. Delete protection is two independent locks — ours and the provider’s native one, either enough to refuse — enforced at the deletion itself rather than on an API route, so it also blocks a rebuild and a delete arriving from an automation or a background job.
- Two independent locks, and either one refuses — enforced at the deletion, so a rebuild and an automation are covered too
- Deleting asks for the server’s name, and re-authentication where your organisation requires it
- Stop tracking is reversible and takes no re-auth: history, tags, custom fields and settings all come back
- Untracked servers are hidden everywhere at once — list, dashboards, cost, poller, alert rules, exporter — via a global scope, not a filter each caller has to remember
- A count and a filter are the way back, so nothing you stopped tracking is ever actually lost
Delete — the machine goes
Destroys mail-01 at your provider. The billing stops.
At TransIP this is a cancellation: the machine keeps running until the end of the period you have already paid for.
Of your accounts, only TransIP works that way — and the confirmation says which of the two you are about to do.
Type the server name to confirm deletion:
Plus your organisation’s re-authentication where it is required — passkey, code or password. The capability check runs first, so you are never asked for a passkey for an action the provider was never going to allow.
Stop tracking — the machine stays
mail-01 will disappear from your server list, monitoring and cost reports. Nothing happens to the machine itself.
The server keeps running and your provider keeps charging for it. To stop paying, delete it at the provider instead.
You can bring it back at any time from Servers → Not tracked. Its metrics, tags and settings are kept.
No re-authentication, deliberately: gating the reversible button would push people towards the one that is not.
Two locks, and either one is enough to refuse
InfraNest’s delete lock
Guards deletion, rebuild and restore through InfraNest (and, where supported, the provider). It can’t stop changes made in your provider’s own dashboard.
TransIP’s own protection
TransIP declares no protection of its own, so ours is the only lock. That is not reported as “off” — the cloud simply never offered one.
Enforced at the deletion itself rather than on the API route, so it also refuses a rebuild, and a delete arriving from an automation or a background job.
Everything else it handles
The parts that are only interesting when you need them.
Create a server without leaving InfraNest
Pick the account, then the name, size, location and image — fetched live from your provider, so you only see what you can actually order. Locations grouped by continent, plans grouped into the families that cloud sells with the cheapest first, and a plan your location cannot build greyed out with the reason. The name rule is your provider’s and the form knows it: a capital is lowercased as you type, anything else it cannot accept comes with a one-click fix, and if the name is taken the same button offers the next free one. Ready-made application images get their own tab, and a firewall can be attached in the create call itself.
Only what your cloud can actually do
Every control is gated on a capability the provider declared, never on its name — the page asks “can this be rescued?”, not “is this Hetzner?”. Capabilities fail closed, and are tested against the driver in both directions: a config claiming a feature the driver refuses gives you a button whose only outcome is an error, and one denying a feature the driver has gives you something nobody can reach, which looks exactly like working software. That second test is how we found that TransIP can order and cancel its paid backup add-on and that OVHcloud has a real rescue mode. What a cloud has never declared is left alone rather than reported as off.
Backups and snapshots
Provider backups: enable, trigger one now, restore, delete. Snapshots are your own point-in-time images — create, restore, rename, protect from deletion, delete. Kept snapshots cost money, and the list says how much per month, priced automatically where the provider publishes a rate (on the compressed image size, usually far smaller than the disk) and set by you where it does not. It feeds the Spend report, which is where snapshot sprawl stops being a hunch and becomes a number.
Volumes
Create, attach, detach, resize, rename and delete across providers. A volume only ever grows — your provider’s rule, not ours, and the field says so rather than failing after you click. The resize warning is the useful part: it grows the disk and not the filesystem, and hands you the exact resize2fs or xfs_growfs command to run afterwards. Naming rules are stated under the field per provider, and because DigitalOcean fixes a volume’s name at creation, the page warns you that the name you pick there is permanent.
Load balancers
The services it listens on and forwards to, the targets behind it, and the balancing method. Add a target, remove a target and change the algorithm are also available as automation actions, so a deploy can take a server out of rotation and put it back.
Reserved IPs, and the money in them
Every reserved, floating and elastic address across your accounts, with the server it points at, its reverse DNS, its location and its monthly cost. The unattached ones are the point: providers charge for a reserved address whether or not it is doing anything, and one left behind by a deleted server is on no server’s page, because it is on no server. A banner counts them and totals what they cost. Reverse DNS is editable from either side, with next-free-address prefill for an IPv6 block, validated against the server’s assigned range before it is applied.
Servers we do not manage
A machine with no cloud account behind it — bare metal, a box under a desk, a VM at a provider we have not integrated — can be added and monitored like any other, marked Self-managed. It is deliberately not on the Servers page, because everything that page is for needs a provider API, and it would arrive as a row with every action greyed and every column empty. A count links through to Monitoring so it is never lost, and installing the agent gives you the full picture anyway: CPU, memory, disk, load, services, processes, alert rules and silence detection.
Automatable, and audited
Power a server on, reboot it, shut it down, turn provider backups on or off, toggle delete protection, attach or resize a volume, add or remove a load-balancer target — all available as automation actions. Every change, and every console session, is written to the audit log.
See your own estate in about two minutes
Connect one provider with a read-only token. Nothing is written until you say so.
Provider consoles vs InfraNest
The difference between four tabs and one answer.
Provider consoles
- Four consoles, four mental models, and the estate only in your head
- CPU graphs, and no way to know how full a disk is until it fills
- A plan price per server, with volumes, IPs and snapshots billed somewhere else
- An alert on a one-minute spike, then another when it passes
- Delete and “remove from my list” one menu apart, and only one of them reversible
With InfraNest
- One list across every cloud, with search, filters and tags that span them
- Memory, disk space and load from the machine itself, once a minute
- What each server costs in total, and what your idle volumes and IPs cost you
- An averaging window, a recovery margin, and at most two messages per alert
- Two delete locks, and a confirmation that says which kind of remove this is
One login, ten modules
Every module is in every plan, Free included — what changes is how much of each you get.
The cost of doing it separately
Buy each piece from a different tool and it adds up fast:
- Domain & DNS
- ~€30
- Uptime monitoring
- ~€29
- SSL tracking
- ~€15
- Status page
- ~€29
- Server panel
- ~€15
- Across 4–5 separate tools
- €100–150/mo
Frequently asked
Which clouds are supported?
Hetzner Cloud, DigitalOcean, TransIP and OVHcloud. What you can do differs by provider and is declared rather than assumed: rescue mode, a web console, ISO mounting, placement groups and native delete protection are not offered everywhere, and where a cloud cannot back a control it is greyed out with the reason rather than offered and then failed. OVHcloud is the sharpest case: a VPS there is ordered rather than created from an API call, and removing one cancels a subscription with a notice period — so we send you to OVHcloud’s own panel for both, instead of offering a button that would quietly mean something different from the one beside it. The integrations page lists what works where.
Do I have to install anything?
No. Connect a provider and you get its own metrics — CPU, network and disk throughput, every five minutes — plus the full lifecycle, cost, backups, snapshots, volumes and networks, with nothing on the machine. The agent is optional and adds what no cloud API reports: memory, disk space, load average, uptime, the heaviest processes, what is filling the disk, the state of your services, and an alert when the server stops reporting. It is one command and takes about a minute.
Why can’t my provider report memory or disk space?
Because those numbers only exist inside the machine. A cloud API sits outside the virtual server and can measure what passes through the hypervisor — CPU time, network packets, disk I/O — but it cannot see how much of your RAM is in use or how full your filesystem is, any more than your electricity meter can see what is in your fridge. That is why the agent exists, and why a rule on memory or disk stays greyed out until it is installed rather than being saved as a rule that could never fire.
What does the cost figure include?
The server’s own price plus everything billed alongside it: backups, each attached volume, each attached IP address and snapshot, and any manual line you add yourself, like a licence or a support contract. The IP line matters — with most providers a public IPv4 is billed separately, so a figure without it makes every server look slightly cheaper than it is. Prices are stored and shown net of VAT in the currency your provider quotes, nothing is double-counted against the organisation Spend report, and the total is labelled an estimate: your invoice is the final word.
Will alerts wake me for a one-minute spike?
No. The duration on a rule is an averaging window, not a stopwatch: every reading across those minutes is averaged, and the average is what the threshold is compared against. A backup that pins a core for sixty seconds does not move a fifteen-minute average past 85%. Recovery has a margin too — the average must come back about 10% under the threshold before anything is called recovered — so a value sitting on the line cannot alert and recover all night. You get two messages at most per alert, and if a spike was too short to fire you get nothing at all, not even an all-clear.
What is the difference between deleting a server and stopping tracking?
Delete destroys the machine at your provider, and the billing stops. Stop tracking leaves the machine running and billing, and only removes it from InfraNest — it disappears from the list, dashboards, cost roll-up, metric poller, alert rules and exporter, and it comes back with its history, tags and settings if you track it again. The confirmation dialog says which of the two you are about to do, including whether a delete takes effect now or at the end of a period you have already paid for.
Does a private network need firewall rules between the servers on it?
It depends on the cloud, and InfraNest tells you which one you are on rather than guessing. Every server on a private network can reach every port every other server exposes on its private address, with no allow step in between. On Hetzner the cloud firewall cannot filter that traffic at all — its rules apply to the public interface — so who is attached is the only control. DigitalOcean’s firewalls do filter VPC traffic. Before you confirm an attach, the dialog says which of those applies, read from a capability the provider declared.
Know what your servers are doing, and what they cost
Connect a provider and see your whole estate in one list.
Free plan · No credit card required · Set up in minutes