DEV Community: Frank Zhang

Docker Compose volumes: four mix-ups that can cost you data

Frank Zhang — Tue, 10 Nov 2026 04:17:13 +0000

Most people learn early on that docker compose down followed by up keeps the database. Fewer can say why, and that gap is where data gets lost: someone copies down -v from a tutorial, or assumes :ro protects a volume from everything.

Here's a short quiz. Which of these are true?

A. A volume declared under top-level volumes: but not mounted by any service makes docker compose up fail.

B. Adding :ro to a service's volume mount makes it read-only inside that container.

C. With external: true, Compose looks for an existing volume instead of creating one.

D. A named volume that a service references and that is declared at the top level gets created automatically, using the default driver.

B, C and D are true. A is false. The rest of this post goes through why.

Declaring is not mounting

services:
  app:
    image: alpine:3.21
    command: sleep 3600

volumes:
  app_data:

This is valid. app_data is defined, but nothing uses it, and up doesn't complain. To actually get it into a container you need a service-level mount:

services:
  app:
    image: alpine:3.21
    command: sleep 3600
    volumes:
      - app_data:/data

volumes:
  app_data:

The top-level block defines the volume (and its driver, name, options). The service-level entry attaches it to a path in one container. They're separate steps, and a typo in either one gives you a very different result than you expected.

`:ro` belongs to the mount

volumes:
  - app_data:/data:ro

That's source, destination, and mode. The default mode is rw. The long syntax says the same thing:

volumes:
  - type: volume
    source: app_data
    target: /data
    read_only: true

What :ro blocks is writes through that one mount. Another container can still mount the same volume read-write, and anyone with access to the Docker host can still change the data underneath. A reporting container that reads exports it shouldn't touch is a good use. A data-protection mechanism it is not.

It's also easy to confuse with the service-level read_only: true, which makes the container's root filesystem read-only. Different setting, different problem.

`external: true` hands over lifecycle

Say an admin created the volume beforehand:

docker volume create shared_app_data

and the Compose file points at it:

volumes:
  app_data:
    external: true
    name: shared_app_data

Compose now expects shared_app_data to exist. If it doesn't, up fails; it won't quietly create an empty one. Compose also won't remove it. Without name:, it looks for a volume called app_data exactly as written, with no project prefix.

"External" here has nothing to do with network storage. The volume can live on the same host. The word is about who owns creation and deletion.

Normal named volumes just get created

For an ordinary Compose-managed volume you don't run docker volume create. docker compose up -d makes it if it's missing, using the local driver by default. The name is prefixed with the project name, so key app_data in a project called demo becomes demo_app_data:

docker volume ls
docker volume inspect demo_app_data

`down` vs `down -v`

Command	Containers	Managed named volumes	External volumes
`stop`	stopped	kept	kept
`down`	removed	kept	kept
`down -v`	removed	removed	kept
`up -d --build`	recreated as needed	reused	reused

down -v removes named volumes declared in the Compose file plus anonymous volumes attached to the containers. It won't touch bind-mounted host directories, and it can fail on a volume that's still in use.

Anonymous volumes have a quirk. A plain down leaves them on disk, but since they have no stable name in the Compose file, the next up creates new ones instead of reattaching the old. They're kept, but not reused, and they pile up.

So when someone asks why the database is still there after a rebuild: rebuilding an image doesn't touch volumes. And when someone's data vanished after down -v: that flag asked for exactly that.

A lab you can run

name: volume-lab

services:
  writer:
    image: alpine:3.21
    command: sh -c 'date >> /data/events.log && sleep 3600'
    volumes:
      - app_data:/data

  reader:
    image: alpine:3.21
    command: sleep 3600
    volumes:
      - app_data:/data:ro

volumes:
  app_data:

docker compose up -d
# give the writer a second to create the file, then:
docker compose exec reader cat /data/events.log
docker compose exec reader sh -c 'echo test >> /data/events.log'

The last command should fail with a read-only filesystem error. Now recreate the containers:

docker compose down
docker compose up -d
docker compose exec reader cat /data/events.log

The log now has two timestamps, because the volume outlived the containers. Check it with docker volume inspect volume-lab_app_data.

Only run docker compose down -v here if you want to wipe the lab. Don't paste it into a production directory without checking which volumes it will hit.

Before you deploy something stateful

Check four things:

Is the volume declared where Compose expects it?
Which services mount it, and at which paths?
Does each service really need write access?
Does Compose own this volume, or is it external?

And remember that a volume isn't a backup. It survives container replacement, but not corruption, a mistaken docker volume rm, or a dead disk. Keep backups, and test restoring them.

Synology Ransomware Warning: You Can't Patch a NAS You Haven't Found

Frank Zhang — Thu, 05 Nov 2026 11:59:21 +0000

How to find every Synology NAS on your network, see which DSM version it reports, and check whether that release is still supported.

In October 2026, Synology issued a warning: attackers are targeting NAS devices running outdated DiskStation Manager (DSM). The exploited vulnerability was patched back in December 2024 (SA-24:20), and the ransomware, called C3RB3R, encrypts files and demands a ransom. Other security vendors point to several different DSM vulnerabilities as the entry point, so the safest approach is simple: bring DSM fully up to date.

But before doing that, there's a prerequisite: you need to know exactly which devices you have.

Do you remember how many NAS you have?

Storage devices in homelabs and small offices tend to pile up: the main Synology, an older DiskStation for backups, one in another room, and one you said you'd unplug but never did. Some may not have been logged into for a year, and older models can't all run the latest DSM. Some models top out at DSM 7.4, so "the latest version" depends on the model.

Checking by hand means finding each device's IP, logging in to DSM, and opening the software info page. That's fine for one device, but across a whole network it becomes an inventory job.

What's the most convenient way? Scan first

WiFi Health Check is an iPhone app that scans the Wi-Fi network you're connected to and lists the devices on it. Many Synology NAS units announce themselves over multicast discovery protocols, and when one does, the app can read the model and DSM build the NAS reports about itself, for example a DS920+ running DSM 7.1-42962.

If a NAS doesn't announce itself (multicast discovery is disabled, or the device sits behind VLAN isolation), you'll see a Synology device with the model or version marked "unknown." That's a prompt to check inside DSM. It's a low-probability event, unless your Synology NAS is very old.

For versions it can read, the app also shows whether that DSM release is still within Synology's published support window. Under Synology's lifecycle policy, DSM 7.2 maintenance ended in December 2025, extended support for DSM 7.1 on eligible hardware ended in June 2025, and DSM 7.4, released in June 2026, is maintained through June 2028. Devices running on a branch that's out of support will have to rely on other means of protection.

An example of a practical workflow: first, run a scan, and you'll get an overall report and a list. Fully identified devices appear in it, and your Synology devices are among them. For those that meet the detection conditions, you can go straight to the Synology detail page in the app and view the lifecycle card and recommendations. For those that don't meet the conditions, you'll get a separate-style Synology list, but the specific version numbers need to be looked up manually.

This last step is critical. Once you have the product identification report, the next step is to apply patch updates and security hardening as needed. That's the purpose of the scan: to let you know where you stand ahead of time. WiFi Health Check is a discovery and diagnostic tool; Synology's updates and security protections are the steps that follow.

Then check the basics

Once you know what's on your network:

Install the latest DSM security updates, and turn on automatic updates if possible.
Don't expose the DSM management interface to the internet.
Disable the default administrator account and enable two-factor authentication.
Run Synology's Security Advisor.
Keep at least one verified backup that ransomware can't reach.

The recent PHP2Shell advisories (SA-26:13) involve specific PHP-based packages. Synology's ransomware warning points to SA-24:20, so please treat the two as separate issues.

For a homelab or small office, this is enough to answer a basic question: what's on my network, and which of it needs attention? Windows, Mac, Ubuntu? The product lifecycles of all these systems can be correctly identified.

Next, if you want to know which cameras or NVRs exist on your network, you can also use WiFi Health Check.

As for the tiers of information and reports, this is a boundary worth knowing: it separates the FREE tier from the PRO tier. It's a tier of information density, not a technical ceiling, and you're free to choose.

APPStore: https://apps.apple.com/app/wifi-health-check/id6791147190

Why Run a PHP Probe on Your NAS When Monitoring Can Run in a Container?

Frank Zhang — Mon, 02 Nov 2026 03:59:54 +0000

In October 2026, the C3RB3R ransomware began hitting Synology devices that were exposed to the internet and running outdated DSM. According to reports, the attackers exploited already-disclosed DSM vulnerabilities, encrypted files, and demanded a ransom.

The news brought back something I've never quite understood. Many homelab users monitor their NAS by installing PHP on it, setting up a web server, dropping a probe script into the site directory, and letting an external platform pull data over HTTP. Why not run a separate Docker container that reports outward on its own?

PHP probes have their reasons: they're simple, light, and easy to deploy. But from a maintenance and network-boundary standpoint, the two approaches differ more than you'd expect.

PHP probes: easy to start, tied to the host

The typical flow looks like this: enable PHP on the NAS, configure Nginx or Apache, drop the probe file into the site directory, and have the monitoring platform poll that URL on a schedule.

It's popular for good reasons. You upload one file and it works. Resource usage is low, Docker isn't required, and it runs on older NAS models and most Linux environments. If all you want is CPU, memory, and disk usage, that's enough.

The trouble comes later. Because the probe serves data over HTTP, you can't avoid a few questions. Is the endpoint reachable from the internet? Is there reliable authentication? Is PHP kept up to date? Does the web service account have more privileges than it needs? Can the script read files it shouldn't? Once the probe lives in the NAS's web environment, it becomes one more component you have to maintain.

The real problem is version fragmentation

Real homelabs are rarely a tidy collection of fully updated systems.

Some older models can't move to the latest major DSM version. Some people worry that upgrading will break third-party packages or databases, so they leave a stable system alone. Others simply never get into the habit of checking for updates. To be clear, being unable to upgrade to the latest major version doesn't mean there are no security updates. Synology still ships fixes for some older releases, and whether one exists depends on your model, DSM branch, and the security advisories.

PHP has the same issue. Different models and packages ship different PHP versions, with 7.x and several 8.x branches side by side, different extensions, and different Web Station, Nginx, and Apache configurations. PHP's official support policy is two years of active support followed by two years of security fixes, and then nothing. You can leave the probe script untouched and still end up on a runtime that's long out of support.

Synology's recent PHP2Shell advisory is an example. It affects specific PHP versions and the packages that depend on PHP, such as Web Station, WordPress, and phpMyAdmin. Several PHP branches received fixes. PHP 7.3, which is end-of-life, did not.

One point needs stressing: PHP2Shell and C3RB3R are separate incidents, and nothing here says a PHP probe was the entry point for the ransomware. My point is narrower. Security maintenance can't stop at the operating system. The applications and runtimes on top of it need the same attention.

Docker probes: give monitoring its own runtime

The alternative is to run the monitoring agent in a container, so it carries its own runtime and only makes outbound connections.

       NAS / Linux Server
       ┌──────────────────────┐
       │                      │
       │  DSM / File Services │
       │                      │
       │  Docker Engine       │
       │    ┌──────────────┐  │
       │    │ Docker Probe │  │
       │    │              │  │
       │    │ System Check │  │
       │    │ Asset Probe  │  │
       │    └──────┬───────┘  │
       │           │          │
       └───────────┼──────────┘
                   │
              Outbound Only
                   │
                   ▼
          OpsHome NOC Backend
                   │
          ┌────────┴─────────┐
          │                  │
        iOS App         NOC Console
                            Web

Independent runtime. Dependencies are baked into the image, so it doesn't matter whether the host has PHP, and you don't have to set up a web environment just for the probe. Two NAS units on different DSM versions can run the same image as long as both support containers. The compatibility problems caused by PHP versions, extensions, and web server configs largely go away.

Outbound only, no new entry points. The local agent connects to the monitoring platform, so you don't open an inbound port for the probe, you don't expose the NAS admin interface to the platform, and you don't leave a probe page reachable from the internet. The NAS's existing network boundary stays as it was. Outbound doesn't mean free of security requirements, though. Agent authentication, encrypted transport, credential management, and control over destination addresses are all still needed.

Independent lifecycle. Updating the probe doesn't touch the NAS's PHP. You can pin the image version, restart or redeploy the agent on its own when something breaks at the application layer, and use container resource limits to cap what it takes from the host.

A caveat so nobody misreads this: Docker is not a virtual machine and not an absolute sandbox. Containers share the host kernel. Run one in privileged mode, mount too many directories, or expose the Docker socket, and most of the isolation value is gone. Least privilege still applies.

Side-by-side comparison

	PHP file probe	Docker probe
Runtime	NAS PHP / web environment	Separate container
PHP dependency	Usually required	No dependency on host PHP
Web server	Usually required	Not needed by the probe itself
Dependency management	Affected by the host environment	Managed inside the image
Updates	May involve several components	Can be updated independently
Consistency	Varies by NAS model	Largely consistent on supported platforms
Inbound services	Depends on the access architecture	No new inbound port in outbound mode
Permission boundary	Web service account and script privileges	Container privileges and mount policy
Resource control	Relies on host process management	Container resource limits available

The table doesn't claim PHP is inherently insecure or Docker inherently safe. A well-configured PHP probe that's only reachable from the LAN is perfectly adequate for plenty of people. What differs is whether the runtime is separate, whether the access boundary is clear, and how much effort maintenance takes later.

How we approach it in OpsHome NOC

If all you need is resource usage on one NAS, a simple probe is enough. Once the targets grow to include servers, virtual machines, network devices, domains, and public services, you need a unified platform. OpsHome NOC splits monitoring into two kinds.

Public services are checked directly from outside by the platform: HTTP/HTTPS availability, TCP connectivity, SSL certificate expiry, and domain status. These targets don't need a probe installed.

Private assets such as Synology, Proxmox VE, ESXi, and Ubuntu/Linux servers are collected by a local Docker Probe and reported over an outbound connection, so you don't have to open management ports to the internet for remote monitoring. If an older NAS can't run Docker, don't fight it. Run the Probe on a supported Linux host on the same network and let it do the collection.

Viewing happens in two places. The iOS app is for checking status and incidents wherever you are. NOC Console Web is a read-only central view with Overview, Matrix, Assets, Incidents, and Account pages. It can sit on an office monitor or a server-room wall display, and nothing about it requires opening a device's admin interface to the display. It's separate from Status Pages: Status Pages show public service status to outside visitors, while Console Web shows private assets to administrators.

Monitoring is not ransomware protection

Neither a PHP probe nor a Docker probe replaces the NAS's own security measures. OpsHome NOC is not antivirus software and not a backup system.

The basics still apply. Install DSM and package security updates promptly. Don't expose management ports to the internet. Use strong passwords and multi-factor authentication. Turn off services and ports you don't use. Review access logs regularly. Enable snapshots and keep offline backups, and actually test that you can restore from them. Monitoring helps you notice service failures and dropped connections sooner, but it won't stop an attack from happening.

Wrapping up

PHP probes still have a place. For simple setups with tight resources, a correctly configured script solves the problem. But if you're monitoring many targets over the long term and want one place to manage and view them remotely, it's worth rethinking the deployment: keep inbound entry points to a minimum, put the probe in its own container, use outbound connections for private assets, and keep monitoring separate from device administration.

A NAS exists to store data, and a monitoring platform exists to show you what's going on. Ideally neither drags the other down.

Why Does Docker Compose Keep Your Data After `down`?

Frank Zhang — Sat, 31 Oct 2026 23:21:19 +0000

How Docker volume lifecycles work, why --volumes is dangerous, and how to protect persistent data.

You remove and rebuild your Compose app:

docker compose down
docker compose up -d --build

The containers are brand new, the image is rebuilt, and yet your database, accounts, and settings are all still there.

Is Docker failing to clean up? No. This is exactly how persistent storage is designed to work.

1. Containers and volumes have different lifecycles

A container is disposable. A volume is built to outlive it.

services:
  app:
    image: alpine:3.20
    command: ["sleep", "infinity"]
    volumes:
      - app-data:/data

volumes:
  app-data:

Here app-data is a named volume. Compose creates it and mounts it at /data. When the container is removed, the volume stays on the Docker host.

This is what makes databases, uploads, and configuration survive upgrades.

2. What does `docker compose down` remove?

	`docker compose down`	`docker compose down --volumes`
Containers	Removed	Removed
Compose-managed networks	Removed	Removed
Named volumes (declared in top-level `volumes`)	Kept	Removed
Anonymous volumes	Kept (not reattached by the next `up`)	Removed
`external: true` volumes	Kept	Kept
Host bind mounts	Kept	Kept

Both commands remove containers. The only difference is whether Compose also deletes its persistent storage.

Warning: down --volumes (or -v) permanently deletes that data.

3. Verify it yourself

Start the app and write a file into the volume:

docker compose up -d
docker compose exec app sh -c 'echo "Persistent data!" > /data/check.txt'

Remove and recreate the app:

docker compose down
docker compose up -d
docker compose exec app cat /data/check.txt

Output:

Persistent data!

Now remove the volumes too:

docker compose down --volumes
docker compose up -d
docker compose exec app cat /data/check.txt

This time you get No such file or directory: the old volume was deleted and up created a new, empty one.

This is why rebuilding an image never resets your database. Images and volumes are separate things.

4. A safer approach: `external: true`

For data you cannot afford to lose, manage the volume outside the Compose lifecycle.

Create it once:

docker volume create production-data

Then reference it:

services:
  app:
    image: alpine:3.20
    command: ["sleep", "infinity"]
    volumes:
      - app-data:/data

volumes:
  app-data:
    external: true
    name: production-data

With external: true, Compose treats the volume as an existing resource it does not own:

docker compose down --volumes will not delete it.
If the volume does not exist, docker compose up fails with an error instead of silently creating an empty one. That is a feature: a typo in the name will not give you a blank database.

Note that external: true protects against Compose, not against everything. docker volume rm and docker volume prune can still delete the volume, and it is not a backup.

5. Common commands at a glance

Command	Removes containers	Removes Compose-managed named volumes
`docker compose stop`	No	No
`docker compose down`	Yes	No
`docker compose up -d --build`	Recreates when needed	No
`docker compose down -v`	Yes	Yes

Bind mounts (./data:/var/lib/app) are a different mechanism. Compose never deletes the host directory.

6. Production checklist

Before updating or removing any stateful stack:

List volumes with docker volume ls.
Check what each container actually mounts with docker inspect <container>.
Keep deployment (the Compose file) and data (the volume) separate where possible.
Keep independent, tested backups of databases and application data.
Never use down -v as a routine update command.

Pitfall: changing the project name

Compose prefixes managed volume names with the project name, so app-data becomes myproject_app-data. If you rename the project directory or set a different -p / name:, Compose creates a new, empty volume and your data appears to vanish. The old volume still exists; find it with:

docker volume ls

Mount it again by restoring the original project name, or reference it explicitly with external: true.

Final thoughts

A container is not your data.

Use docker compose down to remove the stack and keep its volumes.
Use docker compose down -v only when you deliberately want to destroy Compose-managed data.
Use external: true when storage should have its own lifecycle.

Knowing the difference can save you from one of the most expensive mistakes in container administration: deleting production data with a single flag.

Docker Compose: Reuse Existing Volumes with external: true

Frank Zhang — Thu, 29 Oct 2026 04:55:13 +0000

Docker Compose: Reuse Existing Volumes with `external: true`

Have you ever deployed a Docker Compose project, only to discover that it created a new volume instead of reusing your existing data?

The solution is simple: external: true.

Why does it happen?

Consider this configuration:

services:
  app:
    image: nginx:alpine
    volumes:
      - app-data:/usr/share/nginx/html

volumes:
  app-data:

By default, Docker Compose manages named volumes as project resources. Depending on the project name, it may create website_app-data instead of using your existing app-data volume.

Your container starts, but the expected data is missing.

The solution

Declare the volume as external:

volumes:
  app-data:
    external: true

Now Compose uses the existing Docker volume named app-data rather than creating a project-managed replacement.

Key points:

No automatic creation: The volume must already exist.
No project-name prefix: Compose uses the specified external volume name.
Independent lifecycle: Compose does not manage the volume as its own resource.

If the volume doesn't exist, Compose reports an error.

Verify your configuration

Create the volume if necessary:

docker volume create app-data
docker volume inspect app-data
docker compose up -d

If the existing volume has a different name, specify it explicitly:

volumes:
  app-data:
    external: true
    name: legacy_website_data

This allows Compose to reference legacy_website_data through the logical key app-data.

Common mistake

Using name alone is not equivalent to external: true. The name property specifies the actual volume name; external: true declares that the volume already exists and is managed outside the current Compose project.

Remember: external volumes are not backups. They can still be deleted manually or lost through storage failure.

Conclusion

When you need Docker Compose to reuse an existing named volume, use:

volumes:
  app-data:
    external: true

One small configuration change can prevent unexpected volume duplication and help preserve data continuity across deployments.

Monitoring a Private Homelab Without Opening a Single Inbound Port

Frank Zhang — Wed, 28 Oct 2026 07:00:58 +0000

Disclosure: I'm the developer of OpsHome NOC, an iOS app and service for monitoring homelabs and small self-hosted environments.

Most monitoring tools ask for something uncomfortable: a port-forward, a VPN, or a publicly exposed management interface. For a homelab, that trade-off is usually the wrong one. This post summarizes how OpsHome NOC approaches it, based on our public security whitepaper.

1. Outbound-only by design

The Docker Probe runs inside a network you authorize and initiates outbound HTTPS connections. In normal operation it needs:

no inbound firewall ports
no router port forwarding
no published internal management interface

Your private infrastructure stays behind your network boundary.

2. Least-privilege Probe

Permissions follow the monitoring features you enable, and the requested access is shown before deployment:

Reaches only targets you authorize
Host data paths mounted read-only
No inbound service port published
No remote shell, Docker Exec, or container-control feature
No customer credential embedded in the published image

3. Credentials and transport

Client and Probe traffic uses encrypted HTTPS
Probe requests are authenticated with replay protection
Supported server-side credentials are encrypted before storage
iOS authentication data is protected by Apple Keychain Services
Full secrets are excluded from application logs

We still recommend dedicated, least-privilege accounts for every integration.

4. What data is (and isn't) kept

Monitoring records (status, events, trends) are limited to the history window of the active plan and removed automatically when it expires. Application secrets and business-file contents are outside the telemetry scope and are not retained as monitoring records. Account deletion triggers an automated deletion process.

5. Don’t take our word for it. Verify it yourself

The whitepaper ties its scan result to an exact image digest, so you can check what you're running. You can also watch the Probe's traffic yourself:

tcpdump -i any host app.opshome.run -nn -A -c 5

Check the digest, published ports, read-only mounts, and outbound connections against the published evidence. The service also publishes SSL Labs A+ and SecurityHeaders.com Grade A results.

Full whitepaper (document OPS-NOC-SEC-2026-V1): https://noc.opshome.run/security.html

Found a problem? The whitepaper lists a security contact, and I'd like to hear about it.

Monitoring your homelab from inside the LAN: public checks, a Docker Probe, and no port forwarding

Frank Zhang — Wed, 28 Oct 2026 04:56:05 +0000

An IT environment doesn't have to be large to be complicated.

A homelab might run Proxmox VE, Docker, a NAS, and a handful of self-hosted apps. A small office might depend on internal servers, business websites, and cloud services. An IT administrator might need to keep an eye on several hosts, many service endpoints, and infrastructure spread across different networks.

The scale differs, but the daily questions are the same: Is the service up right now? Can people reach the internal app? Is the infrastructure healthy? After an outage, can I quickly see what changed? And when users can't reach a service, is there somewhere they can check its status?

OpsHome NOC is a lightweight monitoring and operations platform built around those questions. It combines public service checks, private network monitoring, Docker and infrastructure integrations, incident history, a browser-based Web Console, and Status Pages for external visitors.

Whatever the size of your environment, OpsHome NOC does one thing: it lets you see the state of your services and infrastructure at a glance.

Product website: https://app.opshome.run/
Documentation: https://docs.opshome.run/

What Is OpsHome NOC?

OpsHome NOC is a lightweight network and infrastructure monitoring platform for homelabs, self-hosted services, home offices, small businesses, and any other setting where you need to watch network services and IT infrastructure.

It is built around these capabilities:

Service monitoring: Check public services, plus HTTP, HTTPS, and TCP endpoints inside private networks.
Infrastructure visibility: View Proxmox VE, VMware, Synology NAS, Linux, and Docker environments through integrations.
Events and history: Review state changes, alerts, recoveries, and event timelines.
Mobile operations: Check status anywhere from the iPhone app.
Browser-based operations: Use the Web Console to view monitoring and infrastructure information on a larger screen.
Service status sharing: Show selected service status to users, customers, or other visitors through Status Pages.

OpsHome NOC does not try to replace dedicated log analysis, observability, or infrastructure management platforms. It adds a unified monitoring and status layer on top of the systems you already run.

Current version: OpsHome NOC v1.16 (as of October 2026).

Available metrics and features depend on the platform, connection method, permissions, and the scope of each integration. Please refer to the official documentation and your actual deployment. The sections below describe capabilities directly and do not repeat this caveat.

1. Public Monitoring and Private Network Monitoring

The two kinds of checks answer different questions.

Public monitoring verifies that websites, APIs, and other public endpoints are reachable from the outside. It suits business websites, public services, and SSL certificate checks.

Private network monitoring answers another question: from inside the network where the service actually runs, can it be reached? Typical scenarios include:

Virtualization hosts and self-hosted apps in a homelab;
File servers and internal business apps in a small office;
Websites exposed through a reverse proxy whose backends stay on a private network.

Private network monitoring supports distributed deployment. As long as they belong to the same account, you can run Probes in different places, such as home, the office, a server room, or a VPS, and view them together in one place.

A successful public check doesn't mean your internal apps and infrastructure are healthy. And opening management interfaces just so an external system can monitor internal services creates security risk. The two approaches complement each other, giving you both an outside view and an inside view of your services.

2. Docker Probe: Connecting Private Networks

Docker Probe is the key component of private network monitoring. You deploy it on a Docker host that can reach your target services. It checks the configured services from inside the network and works with infrastructure integrations to collect data.

The Probe connects to OpsHome Cloud over outbound HTTPS. In general you don't need inbound port forwarding, and you don't need to expose internal services to the internet just to monitor them from the cloud.

Typical uses:

Checking internal HTTP and HTTPS services;
Testing TCP service reachability;
Monitoring Docker container status and container events;
Collecting infrastructure information.

Security recommendation: When deploying a Probe, mount the Docker Socket read-only, and use dedicated least-privilege accounts or API tokens for integrations such as Proxmox and Synology.

3. Infrastructure Monitoring: More Than Checking Whether a Port Is Up

A service that answers requests isn't necessarily running on healthy infrastructure. A virtualization host may still be reachable while its storage or virtual machines have problems. A NAS may be online while some of its resources are already abnormal. So besides availability checks, OpsHome NOC provides infrastructure information through integrations:

Proxmox VE: View nodes, virtual machines, LXC containers, storage, and resource metrics. Connect with a dedicated API token and scope its permissions as needed.
VMware ESXi / vSphere: View hosts, virtual machines, datastores, and resource information. The exact fields depend on your actual deployment.
Synology NAS: Depending on DSM version and collection method, view system status, resources, storage, disks, and network information.
Linux and Docker: Combine host information, container status, and service checks to understand the basic health of your runtime environment.

Apply the principle of least privilege to monitoring credentials, and avoid granting unnecessary administrative rights.

4. Incident History and Troubleshooting

The value of monitoring lies not only in spotting problems but also in keeping enough information to see how a problem unfolded.

OpsHome NOC provides an Incident Workspace that links events from monitors and infrastructure assets. It shows active and resolved incidents, severity, duration, affected resources, an evidence timeline, and recovery information. Combined with Docker container events, it helps you tell apart:

A public endpoint that is unreachable;
A private service that failed an internal check;
A container that restarted or entered an abnormal state;
Infrastructure that is reporting an anomaly;
A brief outage that has since recovered on its own.

For the specifics of how much history is kept, see the official documentation: https://docs.opshome.run/

These records help narrow down your investigation, but they cannot automatically diagnose every failure. Root-cause analysis still requires infrastructure management tools and application logs.

5. Web Console: Browser-Based Operations

The mobile app is ideal for quick status checks and receiving alerts. The Web Console is built for viewing your whole environment on a desktop, tablet, or wall display.

Main capabilities:

Monitor matrix: Public checks and private Probe targets in a single matrix, showing availability, latency, protocol, and current state at a glance.
Assets topology: Compute, storage, utilization, and workloads across Synology, Proxmox, VMware, and Linux.
Incident context: Start from an active risk and trace it to affected resources, evidence, and incident history.
Wall display mode: Turn a browser into a long-running status board.
Experience: Light and dark themes, adapted to large desktop displays, iPad, and mobile browsers.

The Web Console is read-only by design. It is for reviewing state and investigating incidents. It provides no infrastructure control and does not replace the management interfaces of Proxmox, VMware, Synology, or Docker. Sign-in uses the same Apple account as the app (Sign in with Apple), and OpsHome never receives or stores your Apple Account password.

What the Web Console displays depends on your plan tier. See Section 9 for the limits of each plan.

To get started, add monitors and assets in the iPhone app, then open https://console.opshome.run/ in a browser. Your data syncs automatically.

Learn more: https://noc.opshome.run/console/

6. Status Pages: Showing Service Status to Users and Customers

Internal monitoring answers "how do operators understand the state of the system?" Service users have a simpler need: Is the service working right now, and is there a known outage?

A Status Page is a public-facing page. You choose which monitors to publish, and visitors can see the following without opening your monitoring dashboard:

The current online state of each service and its latest check;
24-hour, 7-day, and 30-day uptime summaries;
Response times;
Recent incidents and recovery.

Sharing and control:

Share by link or QR code. Scanning the QR code in the OpsHome app verifies that the page was issued by OpsHome.
Access code protection is supported, and sharing duration can be set from 24 hours to permanent.
Public pages never expose real IPs, domains, or internal network details.
You can disable or delete a Status Page at any time from the app.

Typical scenarios: a small business showing customers the status of key services; a self-hosted app operator sharing a status page with users; a homelab owner giving family a single place to check. Meanwhile, administrators keep investigating with their internal tools.

You control what is public. Publish only services that are appropriate to share.

Learn more: https://noc.opshome.run/status-pages/

7. Three Entry Points, Three Roles

Entry point	Main audience	Core purpose
iPhone app (iPad supported)	Operators	Configure monitoring, check status on the go, follow up on alerts
Web Console	Operators	Read-only browser monitoring, asset viewing, wall display
Status Pages	Users, customers, and other visitors	Show the service status the operator chooses to make public

The iPhone app is available anywhere, the Web Console is for deeper observation, and Status Pages handle external communication. Together they cover the whole path from spotting a problem to understanding it to telling others.

8. Scope and Limits

OpsHome NOC suits individuals, small offices, business teams, and IT administrators who want a clear view of how their services are running. How well it fits depends on your devices, integrations, and actual needs.

It is not a replacement for log analysis, metrics platforms, distributed tracing, or security analytics systems, and it doesn't replace sound network segmentation, permission management, and credential protection. Its role is to add a layer of monitoring, observation, and status communication on top of your existing systems.

9. Getting Started

You don't need to connect everything at once. Start with your most important services and expand from there:

Add public monitors for your key websites and APIs.
Deploy a Docker Probe on a host that can reach your private network.
Add Private Monitors for internal apps.
Connect integrations such as Proxmox, VMware, and Synology as your environment requires.
Check status and operations information in the iPhone app or the Web Console.
When you need to communicate externally, set up a Status Page.

Get the App

OpsHome NOC is a free download on the App Store (requires iOS 17.6 or later). Core monitoring works without a subscription and without a credit card:
https://apps.apple.com/us/app/opshome-noc/id6763890679

Plans

	Free	Pro	Studio
Price	$0	$2.99/month or $24.99/year	$5.99/month or $49.99/year
Public monitor targets	30	100	250
Monitor types	HTTP / HTTPS / TCP / SSL / ICMP	All types, including UDP, DNS, Domain	All types and infrastructure integrations
Docker Probes	1 (Synology)	12 (multi-platform)	25 (multi-platform)
Private Monitors	2	50	150
Asset sources	Synology assets	12 (Proxmox VE, VMware vSphere, Linux, Synology)	25
Status Pages	1	3	5, with 20 monitors per page
Minimum check interval	—	3 minutes	3 minutes
Telegram push alerts	—	Custom Telegram setup	Custom Telegram setup
Also included	Push alerts, SSL expiry reminders

Prices are shown in USD. Your App Store may display a different local price.

Founder Benefit: Eligible early accounts registered before May 1, 2027 permanently keep 30 public monitors, 3 Synology Docker Probes, 6 Private Monitors, and 1 Status Page.

Official resources:

Product website: https://app.opshome.run/
Web Console: https://noc.opshome.run/console/
Status Pages: https://noc.opshome.run/status-pages/
Documentation: https://docs.opshome.run/
Docker Probe installation: https://docs.opshome.run/docs/docker-probe/install/
Private HTTP, HTTPS, and TCP monitors: https://docs.opshome.run/docs/private-monitors/http-https-tcp/

Closing

IT environments differ in size and purpose, but the core of monitoring is the same: know whether your services are healthy, understand the state of your infrastructure, and get useful information when something goes wrong.

Through public monitoring, Docker Probe, infrastructure integrations, and incident history, OpsHome NOC helps you keep track of how your services and infrastructure are running. The iPhone app and Web Console serve operators, and Status Pages serve external visitors.

Your Infrastructure. One Glance Away.

Traceroute, Visualized: Turning Raw MTR Hops into a Route You Can Explore

Frank Zhang — Tue, 27 Oct 2026 08:52:18 +0000

A traceroute can tell you which hops responded along a network path. MTR
goes further by repeating probes and collecting latency statistics over
time.

But raw hop data is only part of the story.

When troubleshooting a network, I often want to answer several questions
quickly:

Which network organizations do these hops belong to?
Where does latency change along the route?
Has the path changed since the last test?
Can I understand the route without digging through a long list of IP addresses?

These questions inspired the latest round of improvements to Visual
MTR, a native traceroute and network path diagnostics app for iPhone
and iPad.

The goal is not to turn network troubleshooting into a pretty animation.
It is to make route information easier to explore while preserving the
underlying diagnostic evidence.

1. Preserve the original hop order

A network path should not lose its sequence simply because we want to
visualize it.

In the latest interface, the AS Route view uses a vertical timeline
ordered by the original TTL sequence rather than a row of horizontally
arranged cards.

Each entry provides a compact summary, including the ASN, network
operator, hop number, and average RTT. Expand an entry to inspect more
detailed information, such as the hop IP address, response times, and
estimated geographic location.

This creates two useful levels of detail:

At a glance: Follow the sequence of network organizations and compare latency along the path.
On demand: Drill down into individual hops without losing their position in the original trace.

There is an important distinction here: an ASN-oriented view derived
from observed hops is not the same as a complete BGP AS_PATH. It is a
way to organize the evidence collected by the traceroute, not a claim to
reconstruct every routing decision made by the network.

2. Separate live results from deeper analysis

A diagnostic tool becomes harder to use when every result, chart, and
saved report competes for attention.

Visual MTR now separates the workflow into three areas.

Current Test - Live Hops - Trace Report

Advanced Analysis - MTR Analysis - Globe Report - Route Diff

Test Archive - Test History

The distinction is intentional.

Live results help answer what is happening in the current test. Advanced
analysis helps investigate patterns or compare routes. The archive makes
it easier to revisit previous measurements.

Instead of treating every screen as another version of the same report,
each area has a specific job.

3. Look at latency over multiple rounds

A single traceroute is a snapshot. Network conditions can change between
measurements, and one unusually high RTT does not necessarily indicate
persistent congestion.

Multi-round MTR provides a more useful basis for comparison.

Visual MTR's Pro analysis includes independent statistics for individual
rounds, alongside aggregated results. RTT summaries, trends, and
hop-by-round heatmaps help reveal whether a delay is persistent,
intermittent, or limited to a particular measurement period.

This changes the questions we can ask.

Rather than looking only at the average, we can investigate:

Does latency remain elevated across multiple rounds?
Does the variation appear consistently at the same hop?
Are individual rounds behaving differently from the overall result?
Does a change in the route coincide with a change in observed latency?

These views do not automatically identify the root cause. They make it
easier to determine which part of the path deserves further
investigation.

4. Compare routes instead of relying on memory

Two traces to the same destination may not look identical.

A later test can reveal a different sequence of responding hops, changes
in observed network organizations, or differences in latency
measurements.

The Route Diff view helps make those changes easier to investigate.

Instead of manually comparing two long reports, you can use the
comparison workflow to focus on what changed and then return to the
relevant hop-level details.

This is especially useful when investigating intermittent connectivity,
changes after network maintenance, or differences between tests taken at
different times.

A route difference is evidence, not a diagnosis. Routing policies, load
balancing, transient conditions, and probe-response behavior can all
affect what a trace shows. The next step is to correlate the observed
change with the actual connectivity problem.

5. Explore the route on a 3D globe

The new Globe Report provides another way to inspect a route.

Rather than presenting only a list of hops, it places geographically
locatable hops on an interactive 3D globe. You can rotate and zoom the
globe, select points, and reset the view to explore the displayed route.

The visualization is designed to complement the original trace, not
replace it.

There are two important implementation details.

First, hop order must remain meaningful.

The globe uses a single selected trace round with usable geographic
information. It does not combine hops from different rounds into a
synthetic route. This avoids presenting a visually complete path that
was never observed in any individual round.

Second, geographic information has limits.

IP geolocation provides estimates, not verified physical router
coordinates. The displayed connections represent logical hop order; they
are not verified physical cable routes.

A globe view is useful for understanding the broad geographic context of
a path. Exact latency measurements and the original hop sequence remain
essential for technical analysis.

6. Network diagnostics that fit in your pocket

Visual MTR is designed for situations where opening a laptop is
inconvenient or impossible.

The app provides native IPv4 and IPv6 tracing, per-hop response
information, offline ASN lookup, and configurable DNS settings.

Pro extends the workflow with multi-round MTR, advanced visual analysis,
the 3D Globe Report, Route Diff, and PDF, JSON, and text report exports.
Saved diagnostic history also makes it easier to revisit previous tests.

The app uses a free core workflow with a one-time Pro in-app purchase
rather than a subscription.

The objective is straightforward: make it possible to start with a
simple trace and move into deeper analysis when the problem warrants it,
without forcing every user to navigate the same level of complexity.

7. Visualization should clarify evidence, not overstate it

A good network visualization should make technical information easier to
understand without suggesting more certainty than the measurements
support.

For traceroute and MTR, that means keeping a few principles in mind:

A hop that does not respond to probes is not automatically dropping forwarded traffic.
An ASN summary does not reveal the complete BGP routing state.
An estimated IP location is not the physical location of a router.
A difference between two traces does not, by itself, prove the cause of an incident.
A visual route should remain traceable to the measurements from which it was derived.

These constraints are not limitations to hide. They are part of building
a diagnostic tool that network engineers can trust.

Try Visual MTR

Visual MTR brings native route tracing and visual network path analysis
to iPhone and iPad.

App Store:
https://apps.apple.com/app/visual-mtr-traceroute/id6821332849

The product is still evolving, but the direction is clear: preserve the
original measurements, organize the route intelligently, and give users
better ways to investigate what they see.

If you troubleshoot networks on a mobile device, which view would help
you most: an ordered hop timeline, multi-round latency analysis, route
comparison, or a 3D globe?

I'd be interested to hear how other network engineers approach route
analysis when they are away from their usual workstation.

How to Read MTR Results: Why Packet Loss at One Hop Often Isn't a Problem

Frank Zhang — Sun, 25 Oct 2026 12:33:19 +0000

Have you ever run an MTR, seen 40% packet loss on a router halfway to
your destination, and assumed you had found the culprit?

Often, you haven't. One of the most common mistakes in network
troubleshooting is treating the first unusual number as the root cause.
This guide explains how traceroute and MTR work, how to interpret their
output, and how to avoid blaming the wrong hop.

1. What Does Traceroute Actually Tell You?

Traceroute identifies the intermediate network hops between your device
and a destination.

traceroute example.com

On Windows:

tracert example.com

A typical result looks like this:

1   192.168.1.1       1.2 ms
2   10.20.0.1         8.4 ms
3   203.0.113.10     18.7 ms
4   * * *
5   198.51.100.20    42.1 ms

Each numbered line represents a hop. The time shows how long it took to
receive a response to a probe from that hop. * * * means no response
arrived before the timeout; it does not automatically mean that the
hop is dropping forwarded traffic.

Traceroute has two important limitations:

A single run is only a snapshot. Congestion, routing changes, and wireless interference can produce different results from one run to the next.
It does not reveal the full return path. The route taken by replies from a hop back to your device may differ from the outbound path. A slow response from an intermediate hop does not necessarily mean that ordinary traffic is being forwarded slowly.

2. Why MTR Is More Useful for Troubleshooting

MTR combines traceroute-style path discovery with repeated measurements.
Instead of collecting only one response per hop, it repeatedly probes
the route and accumulates statistics.

Common metrics include:

Loss%: The percentage of probes to that hop that did not receive a response.
Last: The most recent response time.
Avg: The average response time.
Best / Wrst: The lowest and highest response times.
StDev: A measure of how much response times vary.

These numbers help you ask better questions. Is latency consistently
high or only occasionally high? Does response-time variability appear at
a particular hop? Does apparent loss continue all the way to the
destination?

For a shareable text report from a desktop, try:

mtr -rw -c 100 example.com

Here, -r prints a report, -w uses wide output, and -c 100 runs 100
probe cycles. Options for displaying IP addresses or ASN information
vary by MTR version; consult the installed version's manual if you want
to include them.

3. How to Interpret MTR Results Correctly

Consider this simplified example:

Host          Loss%    Avg
Gateway        0%      1.5 ms
Router A       0%      8.2 ms
Router B      35%     12.4 ms
Router C       0%     18.6 ms
Destination    0%     25.1 ms

Router B shows 35% probe loss, but the later hops and destination show
none. This pattern is more consistent with ICMP response rate limiting
or deprioritization than with end-to-end packet loss. Many routers
prioritize forwarding traffic over responding to diagnostic probes, so
they may ignore or delay some replies while continuing to forward
ordinary traffic.

However, this is a diagnostic clue, not definitive proof. Probe
behavior, return paths, and load balancing can complicate the results.

Scenario A: Loss appears at one intermediate hop only

Loss appears at one intermediate hop, while later hops and the
destination are clean. ICMP response rate limiting or deprioritization
is one likely explanation. Do not conclude that the router is faulty
based on that hop alone.

Scenario B: Loss continues to the destination

Compare the previous result with this example:

Host          Loss%    Avg
Gateway        0%      1.5 ms
Router A       0%      8.2 ms
Router B      22%     12.4 ms
Router C      21%     18.6 ms
Destination   23%     25.1 ms

Here, loss begins at Router B and remains visible through subsequent
hops and at the destination. That pattern deserves closer investigation.
Repeat the test at different times and check whether real application
traffic is affected.

Even this pattern does not, by itself, prove that Router B is the cause.
It identifies a point from which further investigation is warranted.

Scenario C: Latency rises and stays high

Response times are low for the first few hops, then increase and remain
elevated. This may point to a longer-distance segment, congestion, or a
routing change. It is a useful lead, not proof of a fault at the first
hop where the increase appears. Remember that response times from
intermediate hops can be affected by their return paths and by how they
prioritize diagnostic traffic.

The key principle: diagnose patterns across the path, not isolated
numbers.

4. A Practical Workflow

Step 1: Establish a baseline. Run a trace to a known destination and
record the route and typical latency.

Step 2: Repeat the measurement. Multiple rounds help distinguish
persistent behavior from short-lived variation.

Step 3: Check the first few hops. If latency or loss appears near
your gateway, investigate Wi-Fi, cabling, and your router. If the local
path looks stable, continue upstream.

Step 4: Compare the suspicious hop with the hops after it. A hop
that fails to answer probes is not necessarily dropping forwarded
traffic.

Step 5: Try a different probe type. Some networks treat ICMP
differently from TCP or UDP. If you suspect ICMP is being limited, try a
TCP-based test toward the port your application actually uses:

mtr -T -P 443 -rw -c 100 example.com

This example uses TCP probes toward port 443. If TCP-based MTR shows no
loss while ICMP-based MTR shows loss, that supports the ICMP
rate-limiting hypothesis, but does not prove it. Different probe types
may follow different ECMP paths or be treated differently by firewalls
and network devices. TCP mode and supported options can also vary by MTR
version.

Step 6: Match the results to the symptom. If SSH sessions drop or an
app slows down, check whether the timing lines up with the trace.
Application logs and other targeted tests can provide additional
evidence.

Step 7: Save the results. Recorded reports make it easier to spot
recurring patterns and explain the problem to an ISP or colleague.

This workflow applies to home networks, cloud servers, remote
administration, and homelabs.

5. Running MTR from an iPhone or iPad

Desktop tools are excellent for deep diagnostics, but problems do not
always happen next to a laptop. You might be at a customer site, using
guest Wi-Fi, or away from your desk and need a quick answer: is the
problem local, or is it farther upstream?

That is why I built Visual MTR: Traceroute, a native iOS and iPadOS
app for route tracing and path analysis.

Free

IPv4 and IPv6 route tracing
Per-hop IP addresses and response times
Adjustable hop limit and probe timeout
Offline IPv4 and IPv6 ASN lookup, so you can see which network each hop belongs to
Up to three configurable DNS servers

Pro Lifetime --- one-time purchase, no subscription

Multi-round MTR with independent statistics for each round
Minimum, average, and maximum RTT, plus RTT variation
RTT trends and hop-by-round heatmaps
Visual ASN route topology
Unlimited saved diagnostic history
PDF, JSON, and text report export

These Pro features map directly to the workflow above. Multiple rounds
and heatmaps help distinguish a one-off spike from a persistent pattern
(Steps 2 and 4), while report export makes it easier to save evidence
and share it (Step 7).

Diagnostic history stays on your device, and ASN lookup works offline
without a cloud account. One important caveat: ASN country labels
reflect registration data, not necessarily the physical location of a
router.

6. Try Visual MTR

A route trace tells you where your probes travel. Repeated measurements
help you understand how the path behaves. The difference between those
two is the difference between guessing and troubleshooting.

A route trace tells you where your probes travel. Repeated measurements help you understand how that path behaves. The difference between those two is the difference between guessing and troubleshooting.

Try Visual MTR: Traceroute for iPhone and iPad.

https://apps.apple.com/us/app/visual-mtr-traceroute/id6821332849

Do You Know What’s Connected to Your Wi-Fi?

Frank Zhang — Sun, 25 Oct 2026 05:48:33 +0000

You can probably name every phone and computer in your home without thinking twice.

But what about the TV, printer, cameras, smart speakers, NAS, and that old tablet you occasionally pull out of a drawer?

As more devices get connected, your home network becomes a small collection of systems quietly working in the background. Then one day, you want to identify an unfamiliar device or troubleshoot a connection—and realize you could use a clearer picture of what’s there.

WiFi Health Check brings device discovery, network diagnostics, walk tests, and stability testing to iPhone and iPad, so you can explore your network directly from your mobile device.

01 | Start by Seeing Who’s on Your Network

Running a LAN scan and watching devices appear in the list is one of the most direct ways to get to know your network.

Phones, computers, printers, cameras, network equipment—devices scattered across different rooms and management interfaces can now be viewed in one place. Device category counts also make it easier to see how your network is made up.

If you have a NAS, virtualization hosts, or smart home devices, this inventory is especially useful. After connecting a new device, you can check whether it has been discovered and view its IP address and identification details.

02 | What Exactly Is That Unfamiliar Device?

The entries that make you pause are often the ones with names you don’t recognize: an unfamiliar hostname, an IP address, or a record that shows only a manufacturer.

WiFi Health Check combines multiple clues to help identify devices, including their manufacturer, device category, model, and discoverable services.

Multicast Discovery is particularly useful here. Devices can announce information through local discovery protocols, and the app combines those details with other probe results to build a more informative device list.

For example, mDNS / Bonjour, SSDP, and WS-Discovery can provide useful clues for identifying Apple devices, printers, media devices, and cameras.

Once you’ve identified a device, you can give it a memorable alias. The next time you see “Office Printer” or “Living Room TV,” you won’t have to work out what it is all over again.

03 | What Has Changed Since the Last Scan?

You’ve installed a new camera, replaced a phone, or rearranged your network equipment. What’s different from your previous scan?

Scan history and device change comparisons let you review results from different points in time, see newly discovered devices, and check which devices were not found in the current scan.

For a home network with plenty of devices—or a small studio—this saves you from repeatedly scrolling through lists and manually comparing addresses. Giving important devices recognizable aliases makes the changes even easier to follow.

Your network inventory now has a timeline: you can inspect the current results and look back at earlier records.

04 | Same Wi-Fi, Different Room—Why Does It Feel Different?

Video streams smoothly in the living room but occasionally stutters in the office. Meetings work well at your desk, yet moving to another room makes the connection feel less dependable.

Start with a network diagnostic to check the current connection. Then use a walk test to test the same target from different locations and compare the results.

You can take measurements in the living room, office, and bedroom, then use those results alongside your everyday needs to decide which location works best for video calls, remote work, or accessing your NAS.

Instead of relying only on “the connection feels unstable here,” you have test records you can revisit when making changes.

05 | It Connects Now. Will It Stay Stable?

A webpage loading successfully tells you that it’s reachable at that moment. For a long video call, a remote connection, or access to services at home, you may also want to know how the connection behaves over time.

Stability testing repeatedly checks a chosen target and tracks metrics such as connection success rate, latency, and jitter.

You can test a service you use regularly or specify an IP address and port to see whether connections keep succeeding and whether latency fluctuates noticeably.

Run a test before and after a network adjustment, and the difference becomes easier to see.

From Knowing Your Devices to Understanding Your Connection

A device inventory helps you get to know your local network. A diagnostic check, a set of walk test results, and a stability test help you understand how it performs in everyday use.

WiFi Health Check brings these tools together on iPhone and iPad, so you can discover devices, explore identification details, review network changes, and check connection performance.

Curious about what’s connected to your own Wi-Fi? Open the app and start with a LAN scan.

Explore WiFi Health Check · View on the App Store

You know your Wi-Fi password. How well do you know the devices behind it?

How to Use Subnet CIDR Pro to Plan IPv4 Networks

Frank Zhang — Mon, 19 Oct 2026 04:56:08 +0000

Subnetting is one of those everyday networking tasks that looks simple until you need to plan multiple VLANs, check address boundaries, or fit several networks into a limited IP range.

A subnet calculator helps with the arithmetic. A good workflow should also help you understand the results and turn them into a usable addressing plan.

In this guide, we'll walk through practical IPv4 subnet calculations, CIDR notation, VLSM planning, and wildcard masks using Subnet CIDR Pro, an offline subnetting tool for iPhone and iPad.

Website: https://subnet.opshome.run/

App Store: https://apps.apple.com/us/app/subnet-cidr-pro/id6816397989

1. Calculate a subnet from an IP address

Let's start with a common example:

192.168.1.100/26

The /26 prefix means that 26 bits identify the network, leaving 6 bits for host addresses.

That gives us:

Total addresses: 64
Conventionally usable host addresses: 62
Subnet mask: 255.255.255.192

Using Subnet CIDR Pro

Open the subnet calculator.
Enter 192.168.1.100 and select the /26 prefix.
Review the calculated network information.
Copy the individual values you need or copy the complete summary.

The result should look like this:

Field	Result
Network	`192.168.1.64/26`
Subnet mask	`255.255.255.192`
First usable address	`192.168.1.65`
Last usable address	`192.168.1.126`
Broadcast address	`192.168.1.127`
Wildcard mask	`0.0.0.63`
Usable hosts	62

Notice that the entered address, 192.168.1.100, is a host address inside the subnet. It is not the network address itself.

This distinction matters when configuring VLAN interfaces, DHCP scopes, firewall rules, and static routes.

2. Understand what happens when the prefix changes

The prefix determines how much address space belongs to a subnet.

For example, compare /24, /26, and /28.

Prefix	Total addresses	Conventional usable hosts
`/24`	256	254
`/26`	64	62
`/28`	16	14

A /24 provides a larger address pool, while a /28 is better suited to a smaller network segment.

In Subnet CIDR Pro, adjust the prefix and review the updated network boundaries, mask, address range, and host capacity.

This is useful when deciding whether a subnet has enough room for the devices you expect to connect.

For example, a VLAN requiring 40 host addresses needs at least a /26 under conventional IPv4 subnetting rules. A /27 only provides 30 usable host addresses.

Don't choose a prefix based only on how many devices are connected today. Leave reasonable room for growth.

3. Plan multiple VLANs with VLSM

Calculating individual subnets is straightforward. Designing an entire addressing plan is more challenging.

Imagine a homelab or small office using the parent network:

10.20.0.0/24

You need separate networks for:

Servers: 100 hosts
Workstations: 50 hosts
Management: 20 hosts
Printers and other devices: 10 hosts

Allocating the same subnet size to every VLAN would waste address space.

This is where Variable Length Subnet Masking (VLSM) becomes useful.

A practical allocation

Start with the largest host requirement and work downward.

Network	Required hosts	Allocation	Usable range
Servers	100	`10.20.0.0/25`	`.1–.126`
Workstations	50	`10.20.0.128/26`	`.129–.190`
Management	20	`10.20.0.192/27`	`.193–.222`
Printers	10	`10.20.0.224/28`	`.225–.238`

The remaining block is 10.20.0.240/28, which can be reserved for future use.

How to use the VLSM planner

Open the VLSM planning feature.
Specify the parent network and the required host counts.
Add meaningful labels for each network.
Generate the allocation plan.
Review the proposed prefixes and address boundaries before deploying them.

The important principle is to allocate the largest requirements first, then fit smaller networks into the remaining address space.

Always verify that every allocated subnet fits within the parent network and that no two allocations overlap.

A structured plan is easier to maintain than a collection of manually calculated addresses.

4. Convert subnet masks and wildcard masks

Subnet masks and wildcard masks are closely related, but they serve different purposes.

For example, a /26 subnet uses:

Subnet mask: 255.255.255.192
Wildcard mask: 0.0.0.63

A wildcard mask is the bitwise inverse of a subnet mask. It is commonly used in Cisco-style access control lists and routing configurations.

Instead of calculating each octet manually, use the mask converter to move between subnet masks, wildcard masks, and CIDR prefixes.

This is especially useful when translating an IP addressing plan into device configurations.

Remember that a wildcard mask is not interchangeable with a subnet mask in every command. Always check the syntax required by the target network device.

5. Use the CIDR reference for quick checks

Sometimes you don't need to calculate a complete subnet. You simply need to answer a question:

How many addresses does /27 contain?
Which subnet mask corresponds to /29?
What wildcard mask should I use for /24?
How many usable hosts are available in a particular prefix?

The built-in CIDR reference lets you look up prefixes from /0 through /32 without repeatedly opening a separate browser-based calculator.

It's useful during troubleshooting, certification study, network planning, and configuration reviews.

6. Pay attention to special prefixes

Not every IPv4 subnet follows the conventional usable-host calculation.

Two important examples are /31 and /32.

/31 — Point-to-point links

RFC 3021 defines the use of /31 prefixes on IPv4 point-to-point links. Both addresses can be used as endpoint addresses in that context, without reserving a traditional network and broadcast address.

/32 — Single-host routes

A /32 identifies one IPv4 address. It is commonly used for host routes and other configurations that refer to a single address.

Subnet CIDR Pro handles these prefix boundaries explicitly, helping avoid incorrect assumptions when working with point-to-point links or single-host routes.

7. Why use an offline subnet calculator?

Network addressing information often appears in internal documentation, private infrastructure plans, and troubleshooting notes.

Subnet CIDR Pro performs its subnet calculations locally on the device. The calculation workflow does not require an account or a backend service, and results are copied only when you choose to copy them.

That makes it convenient when working in a lab, on-site, or in environments where connectivity is limited.

It also means you can calculate subnets without depending on an external website being available.

Final thoughts

Subnetting is not just about finding a network address. It is about making reliable decisions about address capacity, network boundaries, and future growth.

A practical workflow is simple:

Calculate the subnet for an individual IP address.
Adjust the prefix to evaluate address capacity.
Use VLSM to plan multiple networks efficiently.
Convert masks when working with routing or ACL configurations.
Verify special prefixes before deploying the configuration.

Subnet CIDR Pro brings these IPv4 calculation and planning tasks into one focused iPhone and iPad workflow.

If you regularly work with VLANs, homelabs, routing, or small-office networks, having these calculations available offline can make address planning quicker and less error-prone.

Disclosure: Subnet CIDR Pro is my app. This article focuses on practical subnetting workflows rather than a complete feature review.

#devops #homelab #cidr

Does `docker compose down` Delete Your Data?

Frank Zhang — Fri, 16 Oct 2026 14:06:02 +0000

Two commands can have very different consequences for your database:

docker compose down
docker compose down --volumes

The difference comes down to how Docker Compose manages volumes.

Containers are temporary. Named volumes persist.

Consider this PostgreSQL configuration:

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?Set a password}
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

The database files live in db_data, a named volume with a lifecycle separate from the container.

Running docker compose down removes the containers and project networks, but keeps the named volume. Starting the same project again with docker compose up -d reuses the existing data.

Adding --volumes requests removal of the project’s managed volumes too.

Command	Containers	Managed named volumes
`docker compose stop`	Stopped	Kept
`docker compose down`	Removed	Kept
`docker compose down --volumes`	Removed	Removed if possible

Treat --volumes as an intentional data reset.

External volumes are handled differently

To manage storage independently of the Compose stack, create it first:

docker volume create postgres_data

Then update the volume declaration:

volumes:
  db_data:
    external: true
    name: postgres_data

Compose now expects postgres_data to exist and will leave it untouched—even during down --volumes.

However, external volumes can still be deleted manually. Also, pointing an existing application at a new volume does not migrate its old data.

“Empty database” does not always mean deleted data

Compose normally prefixes managed volume names with the project name:

homelab_db_data

Changing the project name—or moving the Compose file when the directory determines that name—can cause the application to use a different volume.

Before assuming data loss, check:

docker volume ls
docker volume inspect homelab_db_data

The original data may still exist in the previous volume.

For routine shutdowns, use stop or down. Reserve down --volumes for deliberate cleanup, and maintain backups for anything you cannot afford to lose.

DEV Community: Frank Zhang

Docker Compose volumes: four mix-ups that can cost you data

Declaring is not mounting

:ro belongs to the mount

external: true hands over lifecycle

Normal named volumes just get created

down vs down -v

A lab you can run

Before you deploy something stateful

Synology Ransomware Warning: You Can't Patch a NAS You Haven't Found

Do you remember how many NAS you have?

What's the most convenient way? Scan first

Then check the basics

Why Run a PHP Probe on Your NAS When Monitoring Can Run in a Container?

PHP probes: easy to start, tied to the host

The real problem is version fragmentation

Docker probes: give monitoring its own runtime

Side-by-side comparison

How we approach it in OpsHome NOC

Monitoring is not ransomware protection

Wrapping up

Further reading

Why Does Docker Compose Keep Your Data After `down`?

1. Containers and volumes have different lifecycles

2. What does docker compose down remove?

3. Verify it yourself

4. A safer approach: external: true

5. Common commands at a glance

6. Production checklist

Pitfall: changing the project name

Final thoughts

Docker Compose: Reuse Existing Volumes with external: true

Docker Compose: Reuse Existing Volumes with external: true

Why does it happen?

The solution

Verify your configuration

Common mistake

Conclusion

Monitoring a Private Homelab Without Opening a Single Inbound Port

1. Outbound-only by design

2. Least-privilege Probe

3. Credentials and transport

4. What data is (and isn't) kept

5. Don’t take our word for it. Verify it yourself

Monitoring your homelab from inside the LAN: public checks, a Docker Probe, and no port forwarding

What Is OpsHome NOC?

1. Public Monitoring and Private Network Monitoring

2. Docker Probe: Connecting Private Networks

3. Infrastructure Monitoring: More Than Checking Whether a Port Is Up

4. Incident History and Troubleshooting

5. Web Console: Browser-Based Operations

6. Status Pages: Showing Service Status to Users and Customers

7. Three Entry Points, Three Roles

8. Scope and Limits

9. Getting Started

Get the App

Plans

Closing

Traceroute, Visualized: Turning Raw MTR Hops into a Route You Can Explore

1. Preserve the original hop order

2. Separate live results from deeper analysis

3. Look at latency over multiple rounds

4. Compare routes instead of relying on memory

5. Explore the route on a 3D globe

6. Network diagnostics that fit in your pocket

7. Visualization should clarify evidence, not overstate it

Try Visual MTR

How to Read MTR Results: Why Packet Loss at One Hop Often Isn't a Problem

1. What Does Traceroute Actually Tell You?

2. Why MTR Is More Useful for Troubleshooting

3. How to Interpret MTR Results Correctly

Scenario A: Loss appears at one intermediate hop only

Scenario B: Loss continues to the destination

Scenario C: Latency rises and stays high

4. A Practical Workflow

5. Running MTR from an iPhone or iPad

Free

Pro Lifetime --- one-time purchase, no subscription

6. Try Visual MTR

Do You Know What’s Connected to Your Wi-Fi?

`:ro` belongs to the mount

`external: true` hands over lifecycle

`down` vs `down -v`

2. What does `docker compose down` remove?

4. A safer approach: `external: true`

Docker Compose: Reuse Existing Volumes with `external: true`