feat: add 5 SEO homelabbing articles + sitemap + robots

- 5 new blog posts (beginners, dashboard, self-hosted apps, reverse proxy, monitoring) - Added sitemap.xml and robots.txt to public/ - Updated blog post template with OpenGraph, Twitter cards, JSON-LD - Claims verified against product (77 templates, 412 routes, 21 MCP tools) Judge unavailable (Codex quota, GLM quota, Qwen auth failed) — deploy verified via build pass.
2026-10-06 21:56:15 -07:00
1 parent df000a4d11
commit 166eb8cde8
@@ -0,0 +1,4 @@
 User-Agent: *
 Allow: /
 Sitemap: https://dashcaddy.net/sitemap.xml
 Host: https://dashcaddy.net
@@ -0,0 +1,17 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url><loc>https://dashcaddy.net/</loc><changefreq>weekly</changefreq><priority>1.0</priority></url>
 <url><loc>https://dashcaddy.net/features/</loc><changefreq>monthly</changefreq><priority>0.9</priority></url>
 <url><loc>https://dashcaddy.net/pricing/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/docs/</loc><changefreq>weekly</changefreq><priority>0.9</priority></url>
 <url><loc>https://dashcaddy.net/docs/installation/</loc><changefreq>monthly</changefreq><priority>0.9</priority></url>
 <url><loc>https://dashcaddy.net/docs/catalog/</loc><changefreq>weekly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/about/</loc><changefreq>monthly</changefreq><priority>0.7</priority></url>
 <url><loc>https://dashcaddy.net/blog/</loc><changefreq>weekly</changefreq><priority>0.9</priority></url>
 <url><loc>https://dashcaddy.net/blog/deploy-self-hosted-apps-with-ai/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/blog/homelab-beginners-guide/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/blog/best-homelab-dashboard/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/blog/best-self-hosted-apps-homelab/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/blog/homelab-reverse-proxy-guide/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 <url><loc>https://dashcaddy.net/blog/homelab-monitoring-guide/</loc><changefreq>monthly</changefreq><priority>0.8</priority></url>
 </urlset>
@@ -65,11 +65,21 @@ export async function generateMetadata({
    title: `${post.title} — DashCaddy Blog`,
    description: post.description,
    alternates: { canonical: `https://dashcaddy.net/blog/${post.slug}/` },
    keywords: post.tags,
    authors: [{ name: post.author }],
    openGraph: {
      title: post.title,
      description: post.description,
      type: "article",
      url: `https://dashcaddy.net/blog/${post.slug}/`,
      publishedTime: `${post.date}T00:00:00Z`,
      authors: [post.author],
      tags: post.tags,
    },
    twitter: {
      card: "summary_large_image",
      title: post.title,
      description: post.description,
    },
  };
 }
@@ -85,9 +95,29 @@ export default async function BlogPostPage({
  if (!post || body === null) notFound();
  const html = marked.parse(body, { async: false }) as string;
  const canonical = `https://dashcaddy.net/blog/${post.slug}/`;
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    description: post.description,
    datePublished: `${post.date}T00:00:00Z`,
    dateModified: `${post.date}T00:00:00Z`,
    author: { "@type": "Person", name: post.author },
    publisher: { "@type": "Organization", name: "DashCaddy" },
    mainEntityOfPage: { "@type": "WebPage", "@id": canonical },
    url: canonical,
    keywords: post.tags.join(", "),
  };
  return (
    <div className="flex min-h-screen flex-col bg-surface-950 text-surface-50">
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{
          __html: JSON.stringify(jsonLd).replace(/</g, "\\u003c"),
        }}
      />
      <Navbar />
      <article className="relative py-16 sm:py-20">
@@ -0,0 +1,195 @@
 The phrase **best homelab dashboard** can describe three very different products:
 a homepage full of links, a monitoring screen full of graphs, or a control panel
 that actually deploys and manages services. Choosing the wrong category is why
 many home server dashboards look impressive but leave the hard work in a terminal.
 The best choice depends on what you want to do after you open the page. This guide
 explains the dashboard categories, the features that matter, and when a platform
 such as DashCaddy is a better fit than a simple start page.
 ## Three types of homelab dashboard
 ### 1. The service homepage
 A homepage organizes links to Jellyfin, Home Assistant, your router, storage, and
 other tools. It replaces browser bookmarks with a clean grid and may show a few
 widgets or availability indicators.
 Choose this category when your services are already configured and you mainly
 need a launchpad. It is lightweight and easy to understand, but it usually does
 not own deployment, networking, certificates, or backups.
 ### 2. The monitoring dashboard
 Monitoring dashboards focus on metrics and history: CPU load, memory, disk space,
 latency, error rates, and uptime. They answer questions such as "when did this
 become slow?" and "is the disk filling up?"
 They are valuable for diagnosis, but they are not necessarily service managers.
 A graph can show that a container is down without giving you a safe deployment or
 configuration workflow.
 ### 3. The management dashboard
 A management dashboard is an operating surface. It knows about applications,
 containers, routes, configuration, health, and lifecycle actions. The objective is
 not just to display the homelab—it is to reduce the number of disconnected tools
 required to run it.
 DashCaddy belongs in this category. It combines an application catalog, deployment
 workflows, Caddy-based connectivity, service health, security visibility, and
 multi-host operations in one interface.
 ## What to look for in the best homelab dashboard
 ### Real service awareness
 A useful dashboard should distinguish between a link and a running service. Look
 for container state, health information, host identity, and a clear record of
 where each application lives. Otherwise the dashboard becomes another document
 you must update by hand.
 ### Deployment that preserves data
 Installing an application involves more than pulling an image. Persistent volumes,
 ports, environment settings, health checks, and restart behavior need consistent
 handling. A good management dashboard makes those choices visible and repeatable.
 ### Reverse proxy and HTTPS integration
 As the number of services grows, direct IP-and-port URLs become difficult to use.
 A dashboard that coordinates hostnames, reverse proxy configuration, and
 certificates removes one of the most repetitive parts of self-hosting. Read the
 [homelab reverse proxy guide](/blog/homelab-reverse-proxy-guide/) for the full
 architecture.
 ### Useful health, not decorative green dots
 "Container running" and "application healthy" are different claims. A process may
 exist while its database is unavailable or its HTTP endpoint returns an error.
 Look for health checks and status detail that help you decide what to inspect next.
 Our [homelab monitoring guide](/blog/homelab-monitoring-guide/) explains the
 layers.
 ### Authentication and access boundaries
 The interface that controls your containers is sensitive. It should not be
 published casually. Keep management access private where possible, use strong
 authentication, and understand which services are meant for family members versus
 administrators.
 ### Backup and recovery visibility
 A dashboard is not a backup, but it should help you understand what data belongs
 to each service and where operational recovery fits. Before trusting a one-click
 installer, ask what is persistent, what is disposable, and how you restore it.
 ### A path from one server to several
 Many homelabs begin on one machine and later spread across a NAS, mini PC, media
 server, or remote VPS. If that is likely, choose a management model that can
 represent hosts explicitly rather than pretending everything runs locally.
 ### An escape hatch for automation
 A GUI is convenient, but APIs make a platform durable. An API or standard tool
 interface lets scripts, CI jobs, and assistants inspect the same system without
 screen scraping. DashCaddy includes registered REST routes, a WebSocket channel
 for live updates, and an MCP server with named operations for compatible AI
 assistants.
 ## How DashCaddy helps home lab users
 DashCaddy was built around a common homelab problem: adding an application creates
 work in several places. The container needs configuration, Caddy needs a route,
 DNS needs a name, TLS needs a certificate path, and the dashboard needs a record.
 When those systems drift apart, routine maintenance becomes detective work.
 DashCaddy brings the workflow together:
 - choose from **77 curated application templates**;
 - deploy and manage services from one interface;
 - coordinate connectivity through Caddy;
 - see service and system health without maintaining a separate bookmark list;
 - view security events and tracked hosts in the Security Center;
 - use natural-language intent and MCP tools for supported operations;
 - extend the same model to multiple hosts as the lab grows.
 That makes it different from a static homepage. A start page points to the work;
 DashCaddy is designed to help perform the work.
 ## When a simple homepage is still the right answer
 Use a lightweight homepage if:
 - every service is already managed through Compose files you are comfortable with;
 - you want links and widgets, not lifecycle control;
 - another platform already owns monitoring, proxying, and certificates;
 - minimal resource use matters more than integration.
 You can also run a homepage alongside a management platform. Family members may
 need a friendly page with five links while the administrator uses a separate,
 private interface for deployment and health.
 ## When DashCaddy is the better fit
 Consider DashCaddy when:
 - you want the dashboard to install and manage applications, not just list them;
 - reverse proxy and certificate work is slowing down each new deployment;
 - you are learning Docker and want curated defaults without losing visibility;
 - the lab spans or may soon span multiple hosts;
 - you want an API and AI-compatible tools in addition to a GUI;
 - you prefer one coherent operating surface over several loosely connected panels.
 The goal is not to hide infrastructure forever. It is to make the common path
 consistent while keeping advanced controls available when you need them.
 ## A practical dashboard evaluation checklist
 Before adopting any home server dashboard, answer these questions:
 - Does it discover or manage real services, or only store links?
 - Can it show the difference between running and healthy?
 - Who can access administrative controls?
 - Where are its own configuration and database backed up?
 - Can it work without a vendor cloud account?
 - How does it handle HTTPS and service names?
 - Can you export, automate, or reproduce its configuration?
 - Does it still make sense when you add a second host?
 - Are updates and failures visible?
 - Can you remove it without losing the applications it helped manage?
 A dashboard should reduce operational uncertainty. If it creates another opaque
 layer, it is not simplifying the homelab.
 ## Frequently asked questions
 ### What is the best homelab dashboard for beginners?
 A beginner benefits from an interface that provides curated application defaults,
 health visibility, and clear networking rather than a blank page of Docker fields.
 DashCaddy is designed for that management role, while a simple homepage may be
 enough if someone else already set up the services.
 ### Is a homelab dashboard the same as monitoring?
 No. A dashboard may organize links or manage applications, while monitoring
 measures state over time and reports failures. Some tools combine parts of both,
 but you should evaluate the actual health and history they provide.
 ### Can a dashboard replace Docker Compose?
 A management platform can generate or manage container configuration, but the
 underlying concepts still matter. Know where volumes, ports, and environment
 settings live so you can recover the service outside the UI if necessary.
 ### Should a homelab dashboard be exposed to the internet?
 Usually not directly. Administrative dashboards are high-value targets. Prefer
 LAN or private-network access, or place the interface behind a carefully configured
 access-control layer.
 Explore the [DashCaddy feature set](/features), browse the [application
 catalog](/docs/catalog), or begin with the [homelab beginner's
 guide](/blog/homelab-beginners-guide/).
@@ -0,0 +1,214 @@
 The **best self-hosted apps** are not the ones that make the longest screenshot.
 They are the services you will use, maintain, and back up. A good first homelab
 stack solves real problems—media, photos, files, passwords, documents, or home
 automation—without creating more administration than value.
 The 15 applications below cover useful categories and are available in
 DashCaddy's curated application catalog. Start with two or three. Add more only
 after monitoring and backups are working.
 ## 1. Jellyfin: your own media server
 Jellyfin organizes and streams media from hardware you control. It is a natural
 first project because the result is visible immediately on televisions, phones,
 and browsers.
 Media servers also teach important homelab lessons: large storage mounts,
 permissions, network throughput, and optional hardware transcoding. Keep the
 media library separate from the application configuration so both can be backed
 up appropriately.
 ## 2. Immich: self-hosted photo backup
 Immich is built around photo and video management, including mobile backup. It is
 one of the most compelling reasons to run a home server because it turns the
 homelab into something family members can use every day.
 Photo libraries are irreplaceable. Treat an Immich deployment as a data-protection
 project, not merely an app install: back up the database and uploaded files, keep
 a second copy off the server, and test restoration.
 ## 3. Nextcloud: files and collaboration
 Nextcloud provides a web-accessible home for files and can support a broader set
 of collaboration features. It is useful when you want a private alternative to a
 collection of cloud storage and productivity services.
 Because it combines an application, database, storage, and background jobs,
 Nextcloud is a good example of why persistent data and health checks matter.
 ## 4. Home Assistant: local home automation
 Home Assistant brings smart-home devices and automations into one locally operated
 platform. A homelab lets those automations continue to work even when an unrelated
 cloud dashboard is unavailable, depending on the devices and integrations you
 choose.
 Place home automation on reliable hardware, document any USB radio mappings, and
 avoid treating experimental updates like disposable web apps.
 ## 5. Pi-hole: network-wide DNS filtering
 Pi-hole filters DNS requests for devices that use it as their resolver. It is
 lightweight, educational, and immediately demonstrates how a service can improve
 the whole network rather than one browser.
 DNS is foundational. If Pi-hole becomes your only resolver, plan a maintenance
 window or secondary path so an app update does not make the internet appear down
 to everyone in the house.
 ## 6. Vaultwarden: a lightweight password vault service
 Vaultwarden provides a self-hosted server compatible with Bitwarden clients. It
 is attractive for home users who want password-vault data on infrastructure they
 control.
 A password vault deserves stricter treatment than a media server: strong admin
 credentials, HTTPS, carefully limited exposure, encrypted backups, and a tested
 recovery plan. Do not make it your first public-facing experiment.
 ## 7. Uptime Kuma: straightforward uptime monitoring
 Uptime Kuma checks HTTP endpoints and other network targets and presents service
 availability in an approachable interface. It answers the first monitoring
 question: "Can I reach this service?"
 Run monitoring early. Without it, homelab failures are often discovered when you
 try to use an application days later. For a broader strategy, read our [homelab
 monitoring guide](/blog/homelab-monitoring-guide/).
 ## 8. Paperless-ngx: searchable document management
 Paperless-ngx turns scanned and digital documents into an organized archive. It
 is useful for receipts, manuals, statements, and household records that would
 otherwise live in folders across several devices.
 Document ingestion and OCR can use more CPU than the idle web interface suggests.
 Store originals safely and include the database, media, and export workflow in
 your backup plan.
 ## 9. Audiobookshelf: audiobooks and podcasts
 Audiobookshelf organizes audiobook and podcast libraries and provides a dedicated
 listening experience. It is a focused alternative to forcing spoken-word media
 into a general music or video server.
 It pairs well with a media-oriented homelab because the storage and backup model
 is familiar, while the application remains useful to nontechnical users.
 ## 10. Mealie: recipes and meal planning
 Mealie is a recipe manager that makes a home server relevant in the kitchen. It
 can centralize recipes and planning instead of leaving them across bookmarks,
 notes, and screenshots.
 This is a good low-risk application for learning reverse proxies and family
 access before exposing more sensitive tools.
 ## 11. Gitea: private Git hosting
 Gitea hosts Git repositories with a web interface. It is valuable for Compose
 files, scripts, documentation, and personal software projects.
 Keep secrets out of repositories even when the server is private. A private Git
 service improves organization; it does not make committed credentials safe.
 ## 12. Syncthing: direct file synchronization
 Syncthing synchronizes folders between devices without turning one web server into
 the center of every transfer. It is useful for keeping selected folders aligned
 across desktops, laptops, and servers.
 Synchronization is not the same as backup. Deletions and unwanted changes may
 propagate. Pair it with snapshots or versioned backups for important files.
 ## 13. BookStack: a home for documentation
 BookStack organizes documentation into a familiar hierarchy. Use it for network
 diagrams, device inventories, recovery steps, warranty information, and the notes
 you will otherwise need during an outage.
 A documented homelab is easier to maintain than a clever one. Record why a service
 exists, where its data lives, and how to restore it.
 ## 14. Stirling PDF: private PDF tools
 Stirling PDF provides browser-based PDF operations on your own server. It is handy
 when you want to merge, split, convert, or reorganize documents without uploading
 them to an unknown website.
 Keep the service private unless you deliberately configure access controls. A
 utility that accepts uploaded documents should not become an anonymous public
 endpoint by accident.
 ## 15. Actual Budget: personal budgeting
 Actual Budget is a self-hosted personal finance application. It demonstrates a
 major benefit of self-hosting: useful software can stay close to the person whose
 data it represents.
 Financial data calls for encrypted transport, strong authentication, reliable
 backups, and restrained network exposure. Understand the import and export paths
 before making it your source of truth.
 ## Which self-hosted apps should you install first?
 Choose one item from each of these layers:
 1. **Daily value:** Jellyfin, Immich, Mealie, or Nextcloud.
 2. **Operations:** Uptime Kuma and a documentation tool such as BookStack.
 3. **Network foundation:** Pi-hole, a reverse proxy, and a private access method.
 4. **Protection:** backups stored outside the application host.
 Avoid installing several databases and storage-heavy applications at once. You
 will learn more by operating three services for a month than by starting thirty
 containers in an afternoon.
 ## How DashCaddy helps manage self-hosted apps
 Every app above has different ports, volumes, health behavior, and access needs.
 DashCaddy reduces that inconsistency with **77 curated templates** that include
 application identity, default networking information, and health-check data.
 For a home lab user, that means:
 - a catalog instead of hunting for a new installation pattern each time;
 - a consistent deployment and lifecycle workflow;
 - Caddy-based reverse proxy and TLS integration;
 - service health in the same interface used for deployment;
 - an inventory that remains useful as the number of applications grows;
 - AI Intent Router and MCP operations for supported catalog, health, and
  container-management tasks.
 The template is a starting point, not permission to ignore the data model. Review
 volumes, credentials, and exposure before every deployment.
 ## Frequently asked questions
 ### What are the best self-hosted apps for beginners?
 Jellyfin, Mealie, BookStack, and Uptime Kuma provide visible value without forcing
 you to start with the most sensitive data. Pi-hole is also beginner-friendly if
 you understand that DNS availability affects the whole network.
 ### How many apps can a home server run?
 That depends on CPU, memory, storage performance, and workload. Idle container
 count is not a useful capacity measure. Photo indexing, media transcoding, and
 databases can create bursts that lightweight dashboards do not.
 ### Are self-hosted apps free?
 Many can be used without a software fee, but the server, storage, electricity,
 domain names, backups, and your maintenance time still have costs. Review each
 project's current license and feature model.
 ### Is self-hosting more private?
 It can reduce dependence on third-party services, but privacy depends on your
 configuration, access controls, logs, backups, and application behavior. Owning
 the server also makes you responsible for securing it.
 Browse all [77 DashCaddy app templates](/docs/catalog), learn [how to build a
 homelab](/blog/homelab-beginners-guide/), or review the [DashCaddy installation
 guide](/docs/installation).
@@ -0,0 +1,195 @@
 A homelab is a server environment you run for yourself: a place to learn Linux,
 host useful applications, keep more data under your control, and experiment
 without putting a business system at risk. It can be one recycled desktop under a
 desk or a rack of machines with storage, networking, and virtualization.
 If you are searching for **how to build a homelab**, the most important advice is
 simple: start with one useful service, not a shopping list. A modest machine that
 you understand is more valuable than an expensive rack you are afraid to change.
 This beginner's guide covers the decisions that matter, the mistakes that create
 unnecessary work, and how DashCaddy can turn a collection of Docker containers
 into an organized home server.
 ## What do you want your homelab to do?
 Choose a first outcome before choosing hardware. Common starting goals include:
 - streaming your own media with Jellyfin;
 - backing up photos with Immich;
 - syncing files through Nextcloud or Syncthing;
 - blocking unwanted network requests with Pi-hole;
 - running Home Assistant for local home automation;
 - learning Docker, Linux, networking, or infrastructure automation.
 One goal gives you a clear definition of "working." After the first service is
 reliable, you can add the second without rebuilding everything.
 ## Step 1: start with hardware you already own
 You do not need enterprise hardware for a first home server. An old desktop,
 small-form-factor office PC, laptop, or modern mini PC can run several lightweight
 containers. Reusing a machine also lets you learn what your workload actually
 needs before spending money.
 Evaluate four resources:
 1. **CPU:** Most dashboards, DNS tools, wikis, and automation services need very
   little. Media transcoding and local AI workloads need more.
 2. **Memory:** Give the operating system room, then budget memory for each service.
   Databases, photo indexing, and virtual machines consume more than simple web
   apps.
 3. **Storage:** Use dependable storage for application data and separate backup
   storage for anything you cannot recreate. Free space is not a backup.
 4. **Network:** Wired Ethernet is preferable for a server. Reserve its IP address
   in your router so bookmarks, DNS records, and proxy routes do not break later.
 Quiet operation and low idle power often matter more at home than benchmark
 scores. A server that is too loud or expensive to leave on will not become useful.
 ## Step 2: choose a simple operating model
 There are three common paths for a beginner homelab:
 - **Linux plus Docker:** the direct route for running containerized applications.
  It has fewer layers and teaches skills that transfer to VPS and cloud servers.
 - **A virtualization host:** useful when you want several virtual machines,
  isolated test environments, or different operating systems on one box.
 - **A NAS-focused operating system:** sensible when storage, snapshots, and file
  sharing are the primary job, with applications as a secondary feature.
 There is no universal winner. If your goal is to run web applications and learn
 self-hosting, a supported Linux distribution with Docker is a strong first step.
 Keep the host boring. Put experiments in containers rather than repeatedly
 changing the base operating system.
 ## Step 3: learn the five Docker concepts that matter
 You do not need to memorize every Docker command. Understand these ideas first:
 - an **image** is the packaged application;
 - a **container** is a running instance of that image;
 - a **volume** or bind mount stores data outside the disposable container layer;
 - a **port mapping** connects the application to the host network;
 - an **environment variable** supplies configuration without editing the image.
 Docker Compose records those choices in a file. That makes a service easier to
 recreate than a command copied from shell history. Keep Compose files and notes in
 version control, but never commit passwords, API keys, or private certificates.
 ## Step 4: give services stable names
 A pile of addresses such as `192.168.1.20:8096` becomes difficult to remember.
 Plan naming early:
 - reserve a stable LAN address for the server;
 - use local DNS so names point to the correct host;
 - put a reverse proxy in front of web applications;
 - use HTTPS instead of training yourself to ignore browser warnings.
 A reverse proxy lets several applications share ports 80 and 443. The requested
 hostname decides which backend receives the traffic. Our [homelab reverse proxy
 guide](/blog/homelab-reverse-proxy-guide/) explains the pattern in detail.
 ## Step 5: install your first applications in a useful order
 A practical first sequence is:
 1. **A dashboard or management layer** so you can see what you have.
 2. **One application you will actually use** every week.
 3. **Monitoring** so failure is visible before someone asks why the service is
   down.
 4. **Backups** for configuration and irreplaceable data.
 5. **Remote access** through a VPN or another deliberately secured path.
 Do not deploy twenty applications on day one. Every service adds updates, data,
 credentials, and another failure mode. The [best self-hosted apps for a
 homelab](/blog/best-self-hosted-apps-homelab/) article can help you choose a
 small, useful first set.
 ## Step 6: build a security baseline
 A home server is still a server. Use a few consistent rules:
 - install security updates;
 - use SSH keys and disable password login when practical;
 - expose only the ports you need;
 - keep admin interfaces on the LAN or behind private access;
 - use unique credentials and multi-factor authentication where supported;
 - back up data, then perform a restore test;
 - review logs and failed login activity;
 - do not publish a service to the internet simply because you can.
 Remote access does not always require public exposure. A private network such as
 Tailscale or WireGuard is often easier to reason about for personal admin tools.
 If a service must be public, place it behind HTTPS and understand its
 application-level authentication.
 ## How DashCaddy helps homelab beginners
 The difficult part of a homelab is rarely starting one container. It is repeating
 the surrounding work for every application: ports, volumes, health checks, DNS,
 reverse proxy rules, certificates, status, and upgrades.
 DashCaddy brings those jobs into one interface:
 - **77 curated application templates** provide known app identities, default
  ports, and health-check information instead of a blank form.
 - **Application deployment** and lifecycle controls reduce the amount of Docker
  command memorization needed for routine work.
 - **Caddy integration** handles the reverse-proxy layer and TLS workflow from the
  same platform used to manage the service.
 - **Service health and live updates** give you an operating view rather than a
  page of bookmarks.
 - **AI Intent Router and MCP tools** let compatible assistants search the catalog,
  inspect health, and perform supported operations without inventing commands.
 - **Fleet management** gives you a path beyond one host without discarding the
  workflow you learned on the first machine.
 DashCaddy does not remove the need to understand your data and security choices.
 It removes repetitive glue work so you can spend more time learning what the
 applications do.
 ## A first-week homelab checklist
 By the end of your first week, aim for this—not a rack full of hardware:
 - [ ] one server with a reserved LAN address;
 - [ ] Docker running on a supported Linux host;
 - [ ] one useful application with persistent data;
 - [ ] a memorable hostname and HTTPS plan;
 - [ ] a health check you can see;
 - [ ] a backup stored somewhere other than the server;
 - [ ] a written restore procedure;
 - [ ] an inventory of the services you deployed.
 That foundation scales. Add capacity only when a real workload asks for it.
 ## Frequently asked questions
 ### How much does a beginner homelab cost?
 It can cost nothing beyond electricity if you reuse a computer. Spend later on
 reliable storage, backups, and networking after you know which services matter to
 you.
 ### Do I need a rack or a dedicated server?
 No. A single mini PC or recycled desktop is enough for many Docker-based services.
 Racks solve density and organization problems that beginners usually do not have.
 ### Is a Raspberry Pi enough for a homelab?
 It can be enough for lightweight services, DNS, automation, and learning. Check
 application architecture support and storage reliability before choosing it for
 photo processing, media transcoding, or database-heavy workloads.
 ### What should I install first?
 Install one application that solves a problem you already have, then add
 monitoring and backups. A homelab becomes sustainable when it is useful, not when
 it has the most containers.
 Ready to start? Read the [DashCaddy installation guide](/docs/installation),
 compare the [77 available application templates](/docs/catalog), or learn what to
 look for in a [homelab dashboard](/blog/best-homelab-dashboard/).
@@ -0,0 +1,242 @@
 A homelab is most useful when its services are boring: available when you need
 them, quiet when healthy, and understandable when something fails. **Homelab monitoring**
 is how you get there. It replaces "I think the server is fine" with specific answers
 about hosts, containers, applications, DNS, and storage.
 You do not need an enterprise observability stack on day one. Start with checks
 that lead to an action, then add detail when a real failure shows you what is
 missing.
 ## Monitoring begins with an inventory
 You cannot monitor what you cannot name. Record:
 - each host and its role;
 - every service and the host that runs it;
 - the service URL and internal port;
 - persistent data locations;
 - health-check path or test;
 - backup source and destination;
 - who uses the service;
 - whether it is private or publicly reachable.
 This inventory is one reason a management platform helps. A handwritten dashboard
 and the Docker host can drift apart unless the system that displays the service
 also knows how it is deployed.
 ## The five layers of homelab monitoring
 ### 1. Host monitoring
 Watch the resources that can affect every service:
 - disk capacity and inode use;
 - memory pressure and swap;
 - CPU load and temperature where relevant;
 - filesystem or storage-pool health;
 - network reachability;
 - operating-system update and reboot state.
 Disk alerts should arrive before the filesystem is full. A full root disk can
 break databases, logs, package updates, and container creation at the same time.
 ### 2. Container state
 Docker can tell you whether a container is running, stopped, restarting, or marked
 unhealthy. That is necessary but not sufficient. "Running" means a process exists;
 it does not prove the application can answer a useful request.
 Use restart counts and recent exits as signals. A container that repeatedly
 restarts may look available during a quick glance while failing every few minutes.
 ### 3. Application health
 An application check should exercise a meaningful endpoint. A basic HTTP check
 can confirm that the web server responds. A dedicated health endpoint may also
 check dependencies such as a database or queue.
 A Compose service can define a health check like this:
 ```yaml
 services:
  app:
    image: your-app-image
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://127.0.0.1:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s
 ```
 Use a command that actually exists inside the image, and verify the path returns
 success only when the application is ready. A broken health-check command can
 label a healthy service as unhealthy forever.
 ### 4. User-path monitoring
 The container may be healthy while the route users need is broken. Check the path
 from the client side:
 - does DNS resolve the expected address?
 - does HTTPS present the expected certificate?
 - does the reverse proxy reach the backend?
 - does the login page return a successful status?
 - do WebSockets or uploads work if the app depends on them?
 This catches failures between components rather than only inside one component.
 ### 5. Backup monitoring
 "The backup job ran" is not the same as "the data can be restored." Monitor job
 exit status, backup age, destination capacity, and the existence of expected
 artifacts. Then schedule restore drills.
 A small, verified restore is more valuable than years of green backup notifications
 that nobody has tested.
 ## What should trigger an alert?
 Alert on conditions that need action. Good early alerts include:
 - a service is unreachable for more than a brief transient period;
 - a container is repeatedly restarting;
 - disk space crosses a warning threshold;
 - a backup is missing or older than expected;
 - a certificate approaches expiration unexpectedly;
 - a host disappears;
 - authentication failures or security events cross a meaningful threshold.
 Avoid alerting on every momentary spike. Require several failed checks before
 paging yourself, and send a recovery notice when the condition clears. Otherwise
 normal updates and reboots train you to ignore the monitoring system.
 ## Build a useful homelab status view
 A daily dashboard should answer these questions quickly:
 1. Are all expected hosts reachable?
 2. Which services are healthy, degraded, or stopped?
 3. What changed recently?
 4. Is storage approaching a limit?
 5. Are backups current?
 6. Are public routes and certificates working?
 7. Are there security events worth reviewing?
 Keep deep metrics available for investigation, but do not force every user to
 interpret dozens of graphs just to learn whether Jellyfin is online.
 ## A simple incident workflow
 When a service goes down, check from the outside inward:
 1. Confirm the user-visible failure from another device.
 2. Resolve the hostname and verify the returned address.
 3. Test the reverse proxy and certificate.
 4. Check the application health endpoint.
 5. Inspect container state, restart count, and recent logs.
 6. Check dependent services such as databases and storage mounts.
 7. Check host disk, memory, and network state.
 8. Restore service, then write down the cause and prevention step.
 This order prevents you from restarting healthy containers when the actual problem
 is DNS or a full disk.
 ## How DashCaddy helps monitor a homelab
 DashCaddy links health to the same service inventory used for deployment. Its
 curated templates include health-check information, and the dashboard provides
 service and system health with live updates over a WebSocket channel. That gives
 home lab users a current operating view without manually maintaining a separate
 list of container links.
 DashCaddy also brings related context into the workflow:
 - lifecycle controls for managed applications;
 - host-aware operation as a lab grows beyond one machine;
 - a Security Center for security events and tracked hosts;
 - Caddy connectivity information alongside the backend service;
 - REST routes for automation and MCP tools that can inspect service and system
  health through named operations.
 The result is faster triage: you can start from the application, see where it runs,
 check its health, and move toward the network or host layer without reconstructing
 the environment from memory.
 DashCaddy does not replace every specialized metrics tool. Detailed long-term
 performance analysis may still belong in a dedicated time-series and visualization
 stack. DashCaddy's role is the integrated day-to-day operating surface.
 ## Monitoring mistakes to avoid
 ### Monitoring from the same failure domain
 If the monitoring service runs on the only server it watches, a host outage also
 silences the monitor. Add an external or second-host check for services whose
 availability matters remotely.
 ### Treating auto-restart as a fix
 Restart policies recover from some transient failures. They can also hide a crash
 loop. Track restart frequency and investigate repeated recovery.
 ### Watching metrics but not storage
 Beautiful CPU graphs do not help when the database stops because the disk is full.
 Capacity and backup age are first-class signals.
 ### Exposing the monitoring dashboard publicly
 Monitoring interfaces reveal hostnames, versions, and service structure. Keep
 administrative views private unless you have deliberately designed authentication
 and exposure controls.
 ### Never testing the alert path
 A notification configuration is not complete until you trigger a controlled test
 and confirm the message reaches the intended person.
 ## A minimum monitoring checklist
 For each important service, verify:
 - [ ] container state is visible;
 - [ ] an application-level health check exists;
 - [ ] the user-facing URL is checked;
 - [ ] disk capacity is monitored;
 - [ ] restart loops are detectable;
 - [ ] backup freshness is checked;
 - [ ] recovery notifications work;
 - [ ] there is a short incident note or runbook.
 Add sophistication after this baseline works reliably.
 ## Frequently asked questions
 ### What is the best homelab monitoring tool?
 The best tool covers your actual failure modes without creating unmanageable
 noise. Uptime tools are excellent for reachability, metrics stacks are stronger
 for history and diagnosis, and an integrated management dashboard such as
 DashCaddy connects health to deployment and service inventory.
 ### Is Docker's running status enough?
 No. It proves a process exists, not that the application, database, proxy route,
 or login flow works. Combine container state with application and user-path checks.
 ### How often should I check a home server?
 Match the interval to the service. A frequently used application may justify
 checks every minute, while backup freshness may be checked daily. Avoid intervals
 that create load without changing your response.
 ### Should monitoring restart failed containers automatically?
 Automatic restart can handle known transient failures, but it needs limits and
 restart-loop detection. Always preserve evidence long enough to understand why the
 service failed.
 Continue with the [best homelab dashboard guide](/blog/best-homelab-dashboard/),
 review the [homelab reverse proxy guide](/blog/homelab-reverse-proxy-guide/), or
 browse [DashCaddy's health and management features](/features).
@@ -0,0 +1,212 @@
 A **homelab reverse proxy** gives many applications one organized front door.
 Instead of remembering `192.168.1.50:8096` for Jellyfin and another address for
 every service, you use names such as `jellyfin.example.com`. The proxy receives
 the request, handles HTTPS, and forwards it to the correct application.
 This guide explains reverse proxies, DNS, and certificates without pretending
 that public exposure is required. It also shows why Caddy is a practical choice
 and how DashCaddy removes the repeated configuration around each new service.
 ## What does a reverse proxy do in a homelab?
 A reverse proxy sits between clients and backend applications. It provides three
 core functions:
 1. **Name-based routing:** several services can share ports 80 and 443 because
   the requested hostname selects the backend.
 2. **TLS termination:** HTTPS certificates and encryption are handled in one
   place rather than configured separately inside every app.
 3. **A policy boundary:** logging, headers, authentication, and network rules can
   be applied before a request reaches a service.
 The backend can still use a private address and port. The browser only needs to
 know the public or internal hostname served by the proxy.
 ## Why Caddy is popular for home servers
 Caddy combines a web server and reverse proxy with automatic HTTPS for qualifying
 hostnames. Its configuration is intentionally compact. A basic route can look
 like this:
 ```caddy
 jellyfin.example.com {
    reverse_proxy 192.168.1.50:8096
 }
 ```
 For a publicly validated domain, Caddy can obtain and renew certificates through
 ACME when DNS and network reachability meet the certificate authority's
 requirements. You still need correct DNS and an intentional exposure design;
 automatic HTTPS cannot repair a hostname that points to the wrong place.
 Caddy also has an internal certificate authority for private names. Devices must
 trust that CA's root certificate before browsers will accept those certificates
 without warnings.
 ## Decide whether the service should be public
 Before touching DNS, classify the application.
 ### Keep it private when possible
 Administrative dashboards, hypervisor consoles, router interfaces, storage
 management, and container controls usually belong on the LAN or a private network.
 Remote access can use a VPN-style path such as WireGuard or Tailscale without
 publishing the management interface to everyone on the internet.
 ### Publish only services intended for outside users
 A family photo portal, media service, or public website may need broader access.
 Public exposure adds responsibility:
 - patch the application and proxy;
 - use application authentication;
 - limit unnecessary routes and ports;
 - monitor access and failures;
 - maintain backups;
 - understand how account recovery works.
 A reverse proxy encrypts and routes traffic. It does not turn an insecure
 application into a secure one.
 ## DNS patterns for a homelab reverse proxy
 ### Public DNS
 For a public service, create a record such as `photos.example.com` pointing to the
 address that reaches your proxy. Depending on your network, that may involve a
 home router, a tunnel, or a VPS relay. Certificate validation must be able to prove
 control of the name through the selected ACME challenge.
 ### Internal DNS
 For LAN-only services, local DNS can point `grafana.home.example.com` directly to
 the proxy's private address. This keeps local traffic local and avoids remembering
 ports.
 ### Split DNS
 Split DNS gives the same hostname different answers inside and outside your
 network. Internal clients reach the proxy over its LAN address, while external
 clients use the public path. This can avoid hairpin-routing problems and gives
 users one consistent URL.
 Document which system is authoritative for each zone. Many "proxy problems" are
 actually stale or conflicting DNS records.
 ## A safe manual Caddy workflow
 If you manage Caddy directly, use a repeatable sequence:
 1. Reserve a stable address for the proxy host.
 2. Confirm the backend application is healthy on its private address.
 3. Create the DNS record.
 4. Add one Caddy site block with the correct backend port.
 5. Validate the configuration before reloading it.
 6. Test from an internal client.
 7. If the service is public, test from a genuinely external network.
 8. Verify login, uploads, WebSockets, and any native mobile clients.
 Keep Caddy's data directory persistent. It contains certificate and state data
 that should survive container or package upgrades.
 ## Common reverse proxy problems
 ### 502 Bad Gateway
 A 502 usually means the proxy cannot reach the backend. Check whether the service
 is running, whether the address and port are correct, and whether Docker networks
 or host firewalls permit the connection. Debug the backend path before changing
 certificate settings.
 ### The certificate will not issue
 Check DNS first. Then verify that the selected ACME challenge can reach Caddy or
 update the required DNS record. Carrier-grade NAT, blocked inbound ports, and
 incorrect AAAA records can all make a correct Caddyfile appear broken.
 ### The app redirects to HTTP or the wrong hostname
 Some applications need to know their external URL or trust proxy headers. Caddy
 sets common forwarding headers, but the application may still require its own
 "external URL" or trusted-proxy setting.
 ### The website loads but live updates fail
 Many modern applications use WebSockets. Caddy supports WebSocket proxying, but
 an incorrect path, upstream address, or application base URL can still break the
 connection. Inspect the browser network panel and proxy logs rather than adding
 random headers.
 ### It works outside but not on the LAN
 Your router may not support hairpin NAT, or internal DNS may still point clients
 to the public address. Add an internal DNS override that sends local clients to
 the proxy's LAN address.
 ## Reverse proxy security checklist
 - Expose the proxy, not every backend port.
 - Keep management interfaces private.
 - Use HTTPS and do not normalize clicking through certificate warnings.
 - Protect accounts with strong, unique credentials and MFA where available.
 - Keep Caddy and backend applications updated.
 - Review access logs without storing more sensitive data than you need.
 - Rate-limit or add upstream protection when a public service attracts abuse.
 - Back up proxy configuration and application data.
 - Test certificate renewal and recovery before an expiration becomes urgent.
 ## How DashCaddy helps with reverse proxy and HTTPS
 The manual workflow repeats for every homelab application: choose a name, find the
 port, write a proxy route, coordinate DNS, obtain a certificate, and add the
 service to an inventory.
 DashCaddy ties those steps to the application lifecycle. Its curated templates
 provide default application ports and health information; deployment and Caddy
 connectivity are managed from the same platform. DashCaddy's built-in CA supports
 private certificate workflows, while Caddy provides the proxy layer used to make
 services accessible through stable names.
 For home lab users, the practical benefits are:
 - fewer hand-edited routes that drift away from the running containers;
 - one place to see the service, host, health, and access configuration;
 - less repetitive certificate and proxy work when adding applications;
 - a clearer path from one server to multiple hosts;
 - APIs and MCP tools for supported automation without parsing configuration files.
 You still choose which services should be reachable and who may access them.
 DashCaddy organizes the implementation; it does not make the exposure decision
 for you.
 ## Frequently asked questions
 ### Do I need a domain for a homelab reverse proxy?
 Not always. Publicly trusted certificates normally use a domain you control.
 Private names can use an internal CA if you install its root certificate on your
 devices. A private network can also provide remote access without publishing the
 service.
 ### Is Caddy better than Nginx or Traefik for a homelab?
 All three can work. Caddy is attractive when concise configuration and automatic
 HTTPS are priorities. Nginx has a large ecosystem and extensive low-level control.
 Traefik is popular in label-driven container environments. Choose the model you
 can operate and recover.
 ### Can one Caddy server proxy applications on several machines?
 Yes, if the proxy can reach each backend over a trusted network path. Use stable
 addresses, restrict backend access, and monitor the inter-host connection.
 ### Does a reverse proxy make an application safe to expose?
 No. It provides routing and can provide TLS and policy controls, but the backend
 still needs secure authentication, updates, sensible configuration, and ongoing
 monitoring.
 See how the reverse proxy fits into a complete [beginner homelab
 setup](/blog/homelab-beginners-guide/), explore [DashCaddy's features](/features),
 or follow the [installation guide](/docs/installation).
@@ -14,6 +14,56 @@ export interface PostMeta {
 }
 export const POSTS: PostMeta[] = [
  {
    slug: "homelab-beginners-guide",
    title: "How to Build a Homelab: A Beginner's Home Server Guide",
    description:
      "Learn how to build a homelab from spare hardware, Docker, DNS, HTTPS, monitoring, and backups—and see how DashCaddy simplifies the work.",
    date: "2026-10-06",
    author: "Sami Ahmed",
    tags: ["homelab for beginners", "home server", "docker", "self-hosting"],
    readingMinutes: 7,
  },
  {
    slug: "best-homelab-dashboard",
    title: "Best Homelab Dashboard: What to Look For in 2026",
    description:
      "Compare homelab dashboard types and learn which deployment, health, HTTPS, security, and automation features make a home server easier to manage.",
    date: "2026-10-06",
    author: "Sami Ahmed",
    tags: ["best homelab dashboard", "home server dashboard", "docker", "monitoring"],
    readingMinutes: 7,
  },
  {
    slug: "best-self-hosted-apps-homelab",
    title: "15 Best Self-Hosted Apps for Your Homelab in 2026",
    description:
      "Discover 15 useful self-hosted apps for media, photos, files, automation, monitoring, and privacy—all available in DashCaddy's app catalog.",
    date: "2026-10-06",
    author: "Sami Ahmed",
    tags: ["best self-hosted apps", "homelab apps", "home server", "docker"],
    readingMinutes: 7,
  },
  {
    slug: "homelab-reverse-proxy-guide",
    title: "Homelab Reverse Proxy Guide: HTTPS, DNS, and Caddy",
    description:
      "Learn how a homelab reverse proxy connects DNS, HTTPS, Caddy, and private services—and how DashCaddy reduces repeated configuration work.",
    date: "2026-10-06",
    author: "Sami Ahmed",
    tags: ["homelab reverse proxy", "caddy", "https", "dns"],
    readingMinutes: 7,
  },
  {
    slug: "homelab-monitoring-guide",
    title: "Homelab Monitoring: Know When a Docker Service Goes Down",
    description:
      "Build practical homelab monitoring across hosts, Docker, application health, DNS, HTTPS, and backups, with DashCaddy as the operating view.",
    date: "2026-10-06",
    author: "Sami Ahmed",
    tags: ["homelab monitoring", "docker monitoring", "health checks", "home server"],
    readingMinutes: 7,
  },
  {
    slug: "deploy-self-hosted-apps-with-ai",
    title: "Deploy Self-Hosted Apps From Plain English: DashCaddy's AI Intent Router",