diff --git a/public/robots.txt b/public/robots.txt
new file mode 100644
index 0000000..5174768
--- /dev/null
+++ b/public/robots.txt
@@ -0,0 +1,4 @@
+User-Agent: *
+Allow: /
+Sitemap: https://dashcaddy.net/sitemap.xml
+Host: https://dashcaddy.net
diff --git a/public/sitemap.xml b/public/sitemap.xml
new file mode 100644
index 0000000..7bead98
--- /dev/null
+++ b/public/sitemap.xml
@@ -0,0 +1,17 @@
+
+
+https://dashcaddy.net/weekly1.0
+https://dashcaddy.net/features/monthly0.9
+https://dashcaddy.net/pricing/monthly0.8
+https://dashcaddy.net/docs/weekly0.9
+https://dashcaddy.net/docs/installation/monthly0.9
+https://dashcaddy.net/docs/catalog/weekly0.8
+https://dashcaddy.net/about/monthly0.7
+https://dashcaddy.net/blog/weekly0.9
+https://dashcaddy.net/blog/deploy-self-hosted-apps-with-ai/monthly0.8
+https://dashcaddy.net/blog/homelab-beginners-guide/monthly0.8
+https://dashcaddy.net/blog/best-homelab-dashboard/monthly0.8
+https://dashcaddy.net/blog/best-self-hosted-apps-homelab/monthly0.8
+https://dashcaddy.net/blog/homelab-reverse-proxy-guide/monthly0.8
+https://dashcaddy.net/blog/homelab-monitoring-guide/monthly0.8
+
diff --git a/src/app/blog/[slug]/page.tsx b/src/app/blog/[slug]/page.tsx
index d33f955..492020b 100644
--- a/src/app/blog/[slug]/page.tsx
+++ b/src/app/blog/[slug]/page.tsx
@@ -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 (
+
diff --git a/src/content/blog/best-homelab-dashboard.md b/src/content/blog/best-homelab-dashboard.md
new file mode 100644
index 0000000..7d8a031
--- /dev/null
+++ b/src/content/blog/best-homelab-dashboard.md
@@ -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/).
diff --git a/src/content/blog/best-self-hosted-apps-homelab.md b/src/content/blog/best-self-hosted-apps-homelab.md
new file mode 100644
index 0000000..2617058
--- /dev/null
+++ b/src/content/blog/best-self-hosted-apps-homelab.md
@@ -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).
diff --git a/src/content/blog/homelab-beginners-guide.md b/src/content/blog/homelab-beginners-guide.md
new file mode 100644
index 0000000..d750f33
--- /dev/null
+++ b/src/content/blog/homelab-beginners-guide.md
@@ -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/).
diff --git a/src/content/blog/homelab-monitoring-guide.md b/src/content/blog/homelab-monitoring-guide.md
new file mode 100644
index 0000000..37db0b6
--- /dev/null
+++ b/src/content/blog/homelab-monitoring-guide.md
@@ -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).
diff --git a/src/content/blog/homelab-reverse-proxy-guide.md b/src/content/blog/homelab-reverse-proxy-guide.md
new file mode 100644
index 0000000..df4ded2
--- /dev/null
+++ b/src/content/blog/homelab-reverse-proxy-guide.md
@@ -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).
diff --git a/src/content/blog/manifest.ts b/src/content/blog/manifest.ts
index 425bdc2..d9c8afa 100644
--- a/src/content/blog/manifest.ts
+++ b/src/content/blog/manifest.ts
@@ -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",