Author name: solarbluseth

Custom PHP Development

Website Restoration & SEO Optimization: Rebuilding Stronger with Recovered Backups

Website Restoration & SEO Optimization: Rebuilding Stronger with Recovered Backups

Posted on: April 18, 2026

AI Assistance: Claude (Sonnet 4.6)


Introduction: When Disaster Becomes Opportunity

We experienced what most web professionals dread—a server crash that left us scrambling to recover critical content and website functionality. But here’s the silver lining: we had backups. Not just any backups, but comprehensive backup files from a previous workstation that contained years of accumulated website assets, configuration files, and content that had been sitting dormant. This session represents a major turning point where we successfully:

  • Migrated from an old computer backup to our current development environment
  • Recovered lost content from the server crash
  • Restored previous session context to understand our development history
  • Implemented a comprehensive SEO optimization strategy across multiple properties
  • Leveraged Claude AI to streamline the restoration and optimization process

This blog post breaks down what we accomplished, the challenges we faced, and the powerful features we implemented to ensure our websites not only recover but thrive in search rankings.


Section 1: The Recovery Challenge—Accessing Years of Backup Data

The Situation

When we discovered the server crash, the initial panic was real. We’d lost recent changes, database snapshots, and workflow context. However, we remembered that we’d migrated from an older computer and still had access to those backup files stored locally. These weren’t fresh backups—they were months old—but they contained valuable assets that existed before the crash occurred.

The recovery process involved:

  • Locating and cataloging backup files: We searched through multiple backup drives and local storage to identify all available recovery points.
  • Validating file integrity: Not all backup files are created equal. We had to verify which files were intact and usable before attempting restoration.
  • Identifying the most recent viable recovery point: Among the backups, we selected the most recent version that didn’t have corruption issues.
  • Extracting and organizing assets: Database dumps, WordPress configurations, theme files, plugin directories, and content archives were extracted and organized for analysis.

The Breakthrough

With Claude AI’s assistance, we created a systematic approach to:

  • Parse database backup files and identify which tables contained critical content
  • Extract WordPress post content, metadata, and relationships
  • Recover theme customizations and Elementor JSON templates
  • Validate user accounts and permissions structures
  • Cross-reference backup data with current infrastructure to identify what needed to be restored vs. what was already present

This process took several hours, but by the end, we had successfully recovered approximately 85% of our pre-crash content, with the remaining 15% either corrupted or already re-created during our recovery efforts.

Digital database backup verification with nested file directories and green checkmarks


Section 2: Loading Previous Session Context—Understanding Our Development History

Why Session Context Matters

Modern development workflows benefit enormously from session continuity. When working on complex projects—especially those involving multiple interconnected systems like our WordPress properties, Elementor templates, and SEO configurations—understanding what was accomplished in previous sessions is critical. It prevents duplicate work, maintains design consistency, and helps developers make informed decisions about architecture.

What We Recovered

By loading our previous session context with Claude AI, we were able to reconstruct:

  • Landing page iterations: We had documented multiple versions of persona-based landing pages, complete with design notes and conversion rate observations.
  • SEO initiatives in progress: Notes on robots.txt hardening, .htaccess optimization, and keyword research across our properties were preserved.
  • Elementor template development: JSON templates for business pages, team grids, and service showcases were recovered and re-analyzed.
  • GTM and GA4 configurations: Container IDs, event tracking setups, and conversion goal definitions were documented and available for verification.
  • Content strategy roadmaps: Blog outlines, content calendar entries, and planned feature releases were accessible.

This context proved invaluable because it meant we didn’t have to reverse-engineer decisions or start from scratch. Instead, we could pick up where we left off and build on our previous work with full awareness of the “why” behind our implementations.

Before and after workspace recovery showing fragmented files and organized project structure


Section 3: Implementing Our Comprehensive SEO Optimization Strategy

The SEO Audit Foundation

With our content restored and context loaded, we launched into a comprehensive SEO optimization strategy. This wasn’t just about quick wins—we wanted to systematically improve our organic visibility across all our properties (solarblu.net, mariehosting.com and betterwebservices.com.

Key SEO Features & Optimizations Implemented

1. Technical SEO Hardening

Robots.txt & .htaccess Optimization: We identified sensitive WordPress paths that were being indexed by Google unnecessarily. Paths like /wp-admin, /wp-includes, /wp-json, and various plugin directories were blocking at the HTTP level and declared as disallowed in robots.txt to prevent crawl budget waste.

XML Sitemap Generation & Validation: We verified that XML sitemaps were being generated correctly for all properties and submitted to Google Search Console with proper indexation.

Canonical Tags & Self-Referential Links: We audited all canonical tag implementations to ensure no self-referential issues and that pagination was handled correctly.

2. Content Optimization & Keyword Strategy

Semantic Keyword Analysis: Using our restored content inventory, we cross-referenced existing content with search trends and competitor analysis. We identified content gaps and opportunities for expansion in high-value keyword clusters.

Meta Tag Improvements: Page titles and meta descriptions were reviewed and optimized with primary and secondary keywords while maintaining readability for click-through rate improvement.

Header Structure Optimization: We audited H1, H2, and H3 tags across pages to ensure proper keyword integration and logical content hierarchy.

3. Core Web Vitals & Site Speed

We conducted performance audits and implemented:

  • Image optimization using modern formats (WebP with JPEG fallbacks)
  • Lazy loading for below-the-fold images and components
  • CSS and JavaScript minification and defer/async loading
  • Browser caching configuration at the Apache2 level
  • Database query optimization in WordPress

4. Internal Linking Strategy

We created a sophisticated internal linking map that:

  • Connected related content through contextual links
  • Distributed page authority efficiently through pillar pages and cluster content
  • Reduced orphaned pages that had no internal links pointing to them
  • Implemented breadcrumb navigation for improved crawlability

5. GA4 & GTM Integration Audit

We conducted a thorough audit of our analytics infrastructure:

  • Google Tag Manager Setup: Verified container configurations and confirmed all tags were firing correctly.
  • GA4 Key Events: Validated conversion tracking for form submissions, page scrolls, document downloads, and other micro-conversions.
  • Cross-domain tracking: For sites with multiple domains, we ensured proper tracking relationships without duplicate counting.
  • User journey analysis: Set up custom reports in GA4 to track content-to-conversion paths and identify high-performing content types.

6. Structured Data & Schema Markup

We implemented rich snippets for:

  • Organization schema: Company details, contact information, and social profiles
  • Product/Service schema: Service offerings with descriptions, pricing, and availability
  • Breadcrumb schema: For improved navigation visibility in search results
  • FAQ schema: For content Q&A sections to appear as featured snippets
  • LocalBusiness schema: For location-specific landing pages and regional targeting

Modern SEO analytics dashboard with Core Web Vitals and keyword rankings


Section 4: Cool Features We Implemented

Feature 1: AI-Assisted Content Recovery & Enhancement

Using Claude AI, we didn’t just restore content—we enhanced it. For blog posts that were partially corrupted or incomplete, we were able to reconstruct the intended message and improve the writing quality. Claude reviewed headlines, meta descriptions, and body content to suggest SEO improvements without changing the core message.

Real Example: A blog post on WordPress hosting tips had lost its introduction and conclusion. Claude analyzed the remaining content, understood the topic and intent, and helped us reconstruct a superior version with better keyword integration and structure.

Feature 2: Automated Meta Tag Generation at Scale

Rather than manually writing meta descriptions for hundreds of pages, we created a Claude-assisted workflow that:

  • Analyzed page content automatically
  • Extracted key topics and keywords
  • Generated unique, compelling meta descriptions within the 160-character limit
  • Flagged descriptions that needed human review for accuracy

This reduced our meta tag optimization from weeks of work to days, with maintained quality and keyword relevance.

Feature 3: Competitive Keyword Gap Analysis

Claude helped us create a systematic analysis process where we:

  • Identified competitor websites in our niche
  • Analyzed their ranking keywords
  • Cross-referenced with our own keyword portfolio
  • Identified high-value keywords we weren’t ranking for
  • Prioritized content creation efforts accordingly

Feature 4: Context-Aware Link Anchor Text Optimization

Instead of generic anchor text like “click here,” Claude reviewed all internal and external links to suggest more descriptive, keyword-rich anchor text that improves both user experience and SEO. The system flagged links where anchor text didn’t accurately describe the target page.

Feature 5: Session-to-Session Knowledge Continuity

Perhaps the most powerful feature was leveraging Claude’s ability to load previous session context. This meant:

  • Claude remembered design decisions from weeks ago without us having to re-explain them
  • Consistency in implementation was maintained across multiple sessions
  • We didn’t duplicate work or contradict earlier decisions
  • Development momentum was preserved even though real-world time passed between sessions

SEO workflow diagram showing Claude AI at center connected to optimization tasks


Section 5: Technical Implementation Details

WordPress Configuration Recovery

We recovered and verified:

  • wp-config.php database credentials and security keys
  • Plugin directory with all active and inactive plugins
  • Theme customizations in theme directories and Elementor settings
  • Uploads directory with all media files
  • WordPress .htaccess rules for pretty permalinks and caching

Database Restoration Strategy

Rather than simply restoring the entire database wholesale (which could have introduced stale data), we:

  • Compared the backup database structure with current production schema
  • Identified new tables and fields added since the backup was created
  • Selectively restored specific tables containing critical content
  • Preserved newer metadata and settings from production
  • Validated referential integrity and foreign key relationships

Version Control & Change Documentation

Throughout the restoration process, we documented:

  • What was recovered and from which backup source
  • What was excluded and why
  • All changes made during the restoration
  • Testing results and validation outcomes
  • Timeline of when content was restored vs. recreated

Section 6: Lessons Learned & Best Practices

Backup Strategy Improvements

This experience reinforced the importance of:

  • Incremental backups: Full backups monthly, incremental weekly
  • Off-site storage: At least one backup copy should be stored geographically separate from production
  • Backup testing: Regular restoration drills to ensure backups are actually usable
  • Backup documentation: Clear labeling of backup contents and creation dates

Development Workflow Improvements

Going forward, we’ve implemented:

  • Environment parity: Development, staging, and production environments now follow identical configurations
  • Automated testing: Database integrity checks run after any restoration attempt
  • Change logs: Every modification to critical files is logged with timestamp and reason
  • AI-assisted documentation: Using Claude to maintain detailed session notes that can be loaded in future sessions

SEO Maintenance Going Forward

We’ve established an ongoing SEO maintenance routine:

  • Weekly: Monitor Core Web Vitals and page speed metrics
  • Bi-weekly: Review GA4 conversion data and identify underperforming pages
  • Monthly: Conduct rank tracking for target keywords and analyze competitor movement
  • Quarterly: Full SEO audit including technical crawl, content review, and backlink analysis

Calendar showing SEO maintenance schedule with color-coded recurring tasks


Section 7: Tools & Technologies Used

AI Assistance

  • Claude (Sonnet 4.6): Primary AI assistant for content recovery, optimization suggestions, workflow design, and session context loading

WordPress Ecosystem

  • WordPress with WP-CLI: Command-line tools for bulk operations
  • Elementor: Page builder with JSON template recovery and optimization
  • phpMyAdmin: Database management and backup analysis
  • Yoast SEO / Rank Math: SEO plugins for on-page optimization and schema markup

Server & Infrastructure

  • Apache2: Web server configuration and .htaccess optimization
  • MySQL/MariaDB: Database restoration and optimization
  • PHP 8.3: Runtime environment for WordPress

Analytics & Monitoring

  • Google Search Console: Indexation status, mobile usability, manual actions
  • Google Analytics 4: Traffic analysis, conversion tracking, user behavior
  • Google Tag Manager: Event tracking and tag deployment

SEO Tools

  • Semrush: Competitive research, keyword analysis, rank tracking
  • Ahrefs: Backlink analysis, content explorer

What’s Next: Future Improvements

This restoration project is just the foundation. Going forward, we’re planning:

  • Content Hub Expansion: Creating topical clusters around high-value keywords with comprehensive pillar pages
  • Automated Reporting: Claude-powered monthly SEO reports that summarize performance changes and recommend actions
  • Core Web Vitals Mastery: Pushing toward perfect scores on all performance metrics

Futuristic roadmap visualization showing future SEO improvements as milestones


Conclusion: From Crisis to Opportunity

What started as a crisis—a server crash that threatened our digital assets—became an opportunity to not only recover what we’d lost but to rebuild our web infrastructure with better practices, stronger security, and a comprehensive SEO strategy.

The ability to access backup files from our old computer, load previous session context with Claude AI, and systematically optimize across all our properties demonstrates the power of:

  • Proper backup procedures and maintaining multiple recovery points
  • AI-assisted workflows that accelerate optimization while maintaining quality
  • Session continuity that preserves institutional knowledge across time
  • Systematic approaches to SEO rather than isolated quick-fixes

Our websites are now stronger, faster, more discoverable in search engines, and better positioned for long-term growth. This comprehensive restoration and optimization project provides a solid foundation for the next phase of our digital strategy.

Special thanks to Claude AI for its assistance in analyzing backup files, suggesting optimizations, maintaining context across sessions, and helping us think through the technical and strategic challenges of this project.


Have you experienced a server crash or needed to recover from a major website issue? Share your experience in the comments below. What backup and recovery strategies have worked best for you? And how are you leveraging AI to accelerate your SEO and content optimization efforts?

Stay tuned for upcoming posts on:

  • Deep dive into landing page optimization and conversion rate improvements
  • How we’re using Claude AI for automated content creation and enhancement
  • Building an AI agent platform with multi-modal capabilities
  • Case studies on converting website traffic to actual revenue

This post was created during an intensive website restoration and SEO optimization session with Claude (Sonnet 4.6) as the primary AI assistant. All code examples, optimization strategies, and technical implementations mentioned have been tested and verified in production environments.About the Author: SolarBluSeth is a web developer and hosting provider with 30+ years of experience, specializing in WordPress optimization, digital marketing strategy, and AI-assisted content creation. He runs solarblu.net, mariehosting.com, and betterwebservices.com.

Custom PHP Development

Celeste AI Agent: Webserver, USB Drive & SMB Sharing Setup

Celeste AI Agent: Webserver, USB Drive & SMB Sharing Setup

Update: After a solid 4 hours of configuration today, Celeste's Raspberry Pi infrastructure is now fully operational with webserver-accessible storage and seamless file sharing across the local network. All components tested and working.

The Setup: What We Built Today

Celeste runs on a Raspberry Pi 4 (8GB RAM, Debian Bookworm) as the brain of a self-hosted AI agent ecosystem. Today's mission was to bridge storage and network access — enabling the Pi's USB external drives to be served via a local webserver and shared to our main desktop using SMB (Server Message Block). The result: centralized file access from anywhere on the network, with Celeste orchestrating the data flow.

System Architecture - Raspberry Pi with USB drives and SMB sharing

Celeste infrastructure: USB storage, webserver, and SMB network bridges

Hardware & Current State

Component Specification
Board Raspberry Pi 4 Model B Rev 1.5
RAM 8GB
OS Debian Bookworm 64-bit (Linux 6.1.21)
Primary Storage 32GB microSD (upgrading to 512GB A2)
External Drive 1 58GB USB (sethdisk1 — npm global, dev files)
External Drive 2 3.7TB USB (sethstudio2 — media, backups)
Webserver Apache2 with PHP (LAMP stack)
File Sharing Samba (SMB/CIFS)
OpenClaw v2026.4.10 (177+ skills)
AI Backend Kimi K2.5 (Moonshot AI) primary, Ollama fallback

Part 1: Webserver Storage Access

Why This Matters

Before today, the USB drives were accessible only via SSH or physical file system access. Now they're served via HTTP — Celeste can fetch files, generate content, and make them immediately available to web clients. This is essential for the AI agent's workflow: read source files → process → output to web-accessible directory → client retrieves.

The Problem We Solved

External USB drives are fast for storage but isolated from network services. The webserver didn't know they existed. Solution: mount the drives in Apache's document root and configure permissions.

Configuration Steps

1. Create mount points for both USB drives:

sudo mkdir -p /var/www/html/storage/sethdisk1
sudo mkdir -p /var/www/html/storage/sethstudio2

2. Mount the USB drives (use your actual device names):

sudo mount /dev/sda1 /var/www/html/storage/sethdisk1
sudo mount /dev/sdb1 /var/www/html/storage/sethstudio2

3. Make mounts permanent in /etc/fstab:

/dev/sda1 /var/www/html/storage/sethdisk1 ext4 defaults,nofail 0 0
/dev/sdb1 /var/www/html/storage/sethstudio2 ext4 defaults,nofail 0 0

4. Fix permissions so Apache can read the drives:

sudo chown -R www-data:www-data /var/www/html/storage
sudo chmod -R 755 /var/www/html/storage

5. Restart Apache to pick up the new directories:

sudo systemctl restart apache2

Verification

Test it from the Pi or your desktop browser:

curl http://192.168.1.xxx/storage/sethdisk1/
curl http://192.168.1.xxx/storage/sethstudio2/

You should see directory listings or file downloads depending on your Apache config. Success: The USB drives are now web-accessible.

Apache webserver with mounted USB drives showing HTTP access

HTTP requests flowing from clients to mounted USB storage via Apache

Part 2: SMB Network Share Setup

Why This Matters

The webserver makes files accessible via HTTP URLs, but for daily workflow, SMB (Samba) lets your desktop see the Pi's drives as a network folder — you can drag-and-drop, edit files directly, and manage them just like local storage. This is the bridge between Celeste's processing and your main machine.

SMB vs HTTP: HTTP = read-only public access. SMB = read-write network shares with authentication. For production Celeste, you want both: HTTP for web clients and Celeste's own workflows, SMB for you to manage files locally.

Install Samba

sudo apt update
sudo apt install samba samba-common-bin -y

Configure Samba for the Storage Directories

Edit /etc/samba/smb.conf and add this at the end:

[sethdisk1]
    comment = Celeste Dev Storage (sethdisk1)
    path = /var/www/html/storage/sethdisk1
    browseable = yes
    read only = no
    guest ok = no
    valid users = @sambagroup
    create mask = 0755
    directory mask = 0755

[sethstudio2]
    comment = Celeste Media & Backups (sethstudio2)
    path = /var/www/html/storage/sethstudio2
    browseable = yes
    read only = no
    guest ok = no
    valid users = @sambagroup
    create mask = 0755
    directory mask = 0755

Set Up SMB User & Permissions

1. Create a Samba user (or use existing Linux user):

sudo smbpasswd -a username

2. Create a group and assign permissions:

sudo groupadd sambagroup
sudo usermod -a -G sambagroup username
sudo chown -R :sambagroup /var/www/html/storage
sudo chmod -R g+rw /var/www/html/storage

Restart Samba

sudo systemctl restart smbd
sudo systemctl restart nmbd

Connect from Your Desktop

Windows: File Explorer → Map Network Drive → \\192.168.1.xxx\sethdisk1

Mac: Finder → Go → Connect to Server → smb://192.168.1.xxx/sethdisk1

Linux:

sudo mount -t cifs //192.168.1.xxx/sethdisk1 /mnt/celeste-disk1 \
  -o username=your_samba_user,password=your_password,uid=1000,gid=1000
Desktop connected to Raspberry Pi via SMB protocol

SMB protocol bridges desktop and Pi for seamless file sharing

Part 3: Integration with Celeste

How Celeste Uses This Setup

The OpenClaw agent (Celeste) now has access to:

  • Web-accessible output directory — Skills can write processed files to /var/www/html/storage and generate shareable URLs for downloads or web previews.
  • SMB input source — You can drop files into the shared folders from your desktop, and Celeste can monitor and process them automatically.
  • Centralized file log — All Celeste's operations (transcripts, generated media, analysis) are stored in a central location accessible from anywhere on the network.

Example Celeste Workflow

User (Discord): "Analyze the video in /storage/sethstudio2/video.mp4"

Celeste:
1. Detects the file via SMB mount on Pi
2. Calls Whisper skill to transcribe audio
3. Calls Claude skill to summarize transcript
4. Writes results to /var/www/html/storage/outputs/
5. Returns HTTP URL to user: http://192.168.1.xxx/storage/outputs/analysis.txt

Security Note

This setup is for a local, trusted network (your home/office). The SMB shares require authentication, but passwords travel in plaintext over the network without additional encryption. For internet-facing deployments, add a VPN layer or use SMB3 with encryption (requires more complex config).

Testing & Verification

Quick Checklist

Webserver: curl http://192.168.1.xxx/storage/ shows directory listing

SMB Browse: Network folder visible on desktop

Read/Write: Can create files via SMB and see them on Pi

Permissions: www-data user can write to storage (for Celeste skills)

Mounts Persistent: Reboot the Pi and drives are still mounted

Architecture Overview

🍓 Pi Storage Layer

USB Drives: 58GB + 3.7TB physical storage

Mount: /var/www/html/storage/

Access: Apache webserver + Samba shares

🤖 Celeste Processing

OpenClaw: 177+ skills orchestrating tasks

I/O: Reads from storage, writes results back

Output: HTTP URLs for web clients

💻 Desktop Access

SMB Mounts: Network drives appear as local folders

Workflow: Drop files, Celeste processes, retrieve results

Real-time: See changes instantly across the network

🌐 Web Clients

HTTP Access: Fetch files via URLs

Public/Private: Configure Apache for both

Scalable: Celeste can serve files to apps, bots, services

Gotchas & Solutions

Mount Points Disappear After Reboot

Fix: Make sure both drives are in /etc/fstab with nofail option. Use UUIDs instead of device names for reliability.

Permission Denied Writing to Shares

Fix: Verify that www-data user and your Samba user are both in the group with write permissions: sudo chown -R :sambagroup /var/www/html/storage && sudo chmod -R g+w /var/www/html/storage

SMB Connection Drops

Fix: Add to /etc/samba/smb.conf in the [global] section: socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE

USB Drive Not Recognized After Disconnection

Fix: Use nofail in fstab to prevent boot failures, and manually remount: sudo mount -a

What's Next

  • SD Card Upgrade: Move from 32GB to 512GB A2-rated microSD for better performance under OpenClaw's heavy I/O workload.
  • Synergy Integration: Share keyboard/mouse across Pi and desktop for unified input experience.
  • Aaron Agent: Deploy a second OpenClaw instance on a VPS for distributed workload handling.
  • Automated Backups: Schedule rsync jobs to backup critical files from sethstudio2 to cloud storage.
  • Web Dashboard: Build a Flask/FastAPI dashboard on the Pi to monitor storage, Celeste status, and recent tasks.
  • OpenClaw Auto-Update: The framework just released v2026.4.11+ — plan the next upgrade carefully to avoid config schema breaks.
Futuristic AI agent ecosystem with multiple servers and cloud integration

Next-gen roadmap: Synergy, Aaron VPS agent, expanded cloud integration

Key Learnings

1. Storage is Upstream: Before spinning up complex agent workflows, nail the data pipeline. Today's 4-hour session paid for itself by eliminating future file access headaches.

2. Permissions Matter: Linux ownership and group permissions are non-negotiable. www-data, sambagroup, and your user all need clear boundaries.

3. Persistent Mounts: USB drives are convenient but fragile. Use /etc/fstab + UUIDs + nofail or face boot failures.

4. Bridging Layers: The webserver layer (HTTP) and file sharing layer (SMB) serve different audiences — Celeste, web clients, and humans. Design for all three.

Command Reference

sudo lsblk                              # List all block devices to find USB drives
sudo blkid                              # Show UUID of each drive
sudo mount /dev/sdX1 /mnt/point         # Mount a drive
sudo umount /mnt/point                  # Unmount a drive
sudo mount -a                           # Re-mount all fstab entries
sudo chown -R user:group /path          # Change ownership recursively
sudo systemctl restart apache2          # Restart webserver
sudo systemctl restart smbd             # Restart Samba daemon
sudo smbclient -L \\\\192.168.1.xxx    # List Samba shares from Linux
mount.cifs                              # Check if CIFS support is installed

📌 Important

All IP addresses in this guide (192.168.1.xxx) are placeholders. Replace with your actual Pi's IP address on your local network. Find it with hostname -I on the Pi.

Resources & Links

Site Updates

The Day the Server Died: How We Rebuilt Four Websites, Survived a PHP Migration, and Why the Hard Drive Still Sits on Our Desk

This is the story we probably should have told from day one. The real story — not the polished version, not the one where everything went according to plan. The one that started with a hard drive failure at the worst possible moment and ended with something we're genuinely proud of. Pull up a chair.

Failed hard drive on a desk

This is the hard drive. We still have it. This is where the story starts.

The Day Everything Stopped

There was no dramatic warning. No flashing lights, no gradual slowdown that gave us time to prepare. One day the self-hosted server that powered everything we had built — years of content, custom themes, client work, databases, email configurations, all of it — simply stopped working. A hard drive failure. The kind that doesn't ask permission and doesn't negotiate.

If you've ever experienced data loss on that scale, you know the feeling. That specific silence when you realize the blinking cursor isn't coming back. The frantic restarts. The realization, slow and heavy, that some of this is gone. Not corrupted, not recoverable with a tool you can download — just gone.

Server chaos and failure

Self-hosting looks great on paper. Until it doesn't.

We ran our own physical server. That was a deliberate choice — control, cost savings, the satisfaction of owning your own infrastructure. And for a long time it worked beautifully. But physical hardware fails. That's not a maybe. That's a when. And our when arrived without ceremony.

Person at computer staring at error screen

The moment every self-hoster dreads. Staring at a black screen that used to be a website.

What we lost: Years of custom-built WordPress themes. Multiple live websites. Databases full of content. Client configurations. Plugin setups that had taken months to tune. Permalink structures, redirects, SEO work. All the little things that you don't realize make up the invisible architecture of a working web presence — until they're not there anymore.

Here's the thing about losing everything though. Once the shock passes — and it does pass — you're left with something surprisingly rare: a completely clean slate. No technical debt. No legacy decisions you made three years ago that you've been quietly living with ever since. No "I'll fix that eventually." Just a blank server and a choice about what to build next and how to build it right.

"Once the shock passes, you're left with something surprisingly rare: a completely clean slate."

The Decision to Start Over — And Do It Better

We could have tried to piece things back together. Scraped what we could from Google's cache, rebuilt from partial backups, patched things into a rough approximation of what existed before. A lot of people would have done exactly that. We almost did.

Instead we made a different call. We decided to treat the failure as an involuntary reset button and use it. Not rebuild what we had — rebuild what we wished we'd had from the start. Cleaner. Faster. Built on standards that would hold up as technology moved forward. Built to last.

Clean WordPress dashboard setup

A fresh WordPress install. Clean database. Correct foundation. The right way this time.

The first decision was moving off self-hosted physical hardware. We'd learned that lesson the hard way. Managed hosting, proper backups, redundancy — these aren't luxuries for serious web properties. They're the baseline. We moved everything to professional hosting infrastructure and haven't looked back.

The second decision was about the foundation itself. Our previous sites ran on fully custom WordPress themes — built from scratch, deeply customized, exactly the way we wanted them visually. They were beautiful. They were also fragile. Tightly coupled to specific PHP versions, difficult to update, incompatible with the direction WordPress tooling was heading. When the server died, those themes became unsalvageable artifacts.

Choosing Astra as the Foundation

We chose Astra as our new base theme. If you know WordPress development you might raise an eyebrow — Astra is widely used, it's not a niche boutique choice. But that's exactly why we chose it. Actively maintained, PHP 8 compatible, performance-focused, and designed to work with every major page builder. It's the reliable chassis that lets you build on top without fighting the foundation.

Setting up Astra theme in WordPress

Astra as the baseline — clean, fast, PHP 8 ready, and built to support what we'd stack on top of it.

The custom work didn't disappear — it evolved. Everything we had built into our custom themes got restructured into Advanced Themer, our own plugin that handles CSS customization, layout control, and custom page components independently of the theme underneath. More on that shortly.

The PHP Migration Nobody Talks About

While we were rebuilding, we hit another wall that doesn't get enough honest coverage in web development circles: the PHP 7.4 to PHP 8 migration.

PHP 8 is not a minor version bump. It's a breaking change for a significant amount of WordPress ecosystem code. Functions that were deprecated got removed. Syntax that PHP 7.4 would quietly handle became fatal errors on PHP 8. And for developers running custom themes — especially ones built years ago with older conventions — this is a wall you hit hard.

PHP 8 code on screen

PHP 8 isn't just an upgrade. For custom codebases, it's a reckoning.

We made a deliberate architectural decision here: rather than spend time patching old custom theme code to limp along on PHP 8, we retired those themes entirely and rebuilt on a compatible foundation. Yes, it meant more work upfront. It meant less work for every year after. That math is simple.

The right call: When your codebase requires expensive maintenance just to keep up with server requirements, it's time to retire it — not patch it. We retired our custom themes, adopted Astra, and invested the saved maintenance time into building something more portable and more powerful instead.

Every site in our network now runs clean PHP 8.3. No deprecated function warnings. No compatibility shims. No anxiety every time a host announces they're dropping PHP 7.4 support.

Building a Proper Plugin Stack

One of the silent failures of our previous setup was the absence of a consistent, well-considered plugin architecture. We had things installed, but it was organic — added as needed, never audited, never rationalized as a system.

The rebuild gave us the chance to be intentional about it. Every site in the SolarBlu network now runs a considered stack built around the same core principles: security first, performance second, functionality third.

WordPress plugin management dashboard

A clean, intentional plugin stack. Every plugin earns its place.

Security shield protecting website

Wordfence on every property. Security isn't optional when you're running multiple live sites.

Wordfence sits at the security layer across all our properties. Proper permalink structures are configured correctly from day one — not retrofitted after content is already published, which causes redirect nightmares and SEO damage. Robots.txt files are deliberate, not default. Sitemaps are generated, submitted, and monitored. Every site is HTTPS. Every site is responsive.

It sounds basic because it is. But basic done correctly is exactly what Google needs to see — and exactly what a lot of rebuilt sites get wrong when they're rushing to get back online.

Not One Website. Four. To Start.

Here's something we want to be honest about, because we think it changes the context of everything else in this post.

We didn't rebuild one website. We rebuilt four of them — simultaneously — while also developing new tooling and learning from every decision we made along the way. Each site had its own database, its own content strategy, its own plugin configuration, its own design requirements.

Four websites on screen Responsive design across devices

Four properties rebuilt. Every one of them responsive, tested, and production-ready.

4
Websites Rebuilt
4
WordPress Installs
PHP 8.3
On Every Property
2yrs
Of Continuous Work

solarblu.net — our main creative and portfolio hub. Home base for SolarBlu, our content, our story, and the work we do.

solarbluseth.com — our personal brand site, connected to our YouTube and TikTok presence, supporting content creation and community building.

mariehosting.com — our hosting services platform, offering managed WordPress hosting, shoutcast streaming hosting, and audio streaming infrastructure for online radio stations and content creators.

betterwebservices.com — our web and internet services platform, focused on fiber optic internet services, web design, and technology solutions for residential and small business clients.

"To start" — because the work doesn't stop at four.

Advanced Themer: From Theme to Plugin

This is the part of the rebuild story we're most proud of, and the part that probably took the most thinking to get right.

Our original custom themes were powerful — but they were monolithic. The design system, the CSS customizations, the custom page layouts, the component library — all of it was baked into the theme itself. Which meant it was tied to the theme. Which meant when the theme had to go, everything went with it.

Plugin development in VS Code

Advanced Themer evolving from a theme dependency into a standalone plugin. Portable. Reusable. Ours.

Advanced Themer started as a theme. It's becoming a plugin. That architectural shift is significant — instead of being locked to a specific theme, it now sits independently in the WordPress ecosystem and can be applied to any project regardless of what theme is underneath. It handles CSS customization, component injection, layout controls, and custom page structures in a way that's portable across projects.

CSS customization on screen

CSS that lives in the plugin layer, not the theme layer. Portable. Updatable. Clean.

The current development milestone is the migration from a Visual Composer-native implementation to a dual-support system that works with both Visual Composer and Elementor via JSON import templates and a section-based strategy. This means the same Advanced Themer component library can be deployed into either page builder ecosystem — significantly expanding the range of projects it can serve.

Page Builders: Visual Composer, Elementor, and the JSON Strategy

When we started the rebuild, Visual Composer was our page builder of choice. We knew it well, we had a workflow around it, and it made sense for the sites we were building at the time.

WordPress page builder interface

Visual Composer gave us the foundation. Now we're building a strategy that works across builders.

But the landscape of WordPress page builders has shifted. Elementor has become the dominant force in the market, and many clients come to us already working in Elementor environments. Building Advanced Themer as a plugin that's builder-agnostic was a direct response to this reality.

JSON template development

The JSON import strategy lets us deploy consistent layouts across different page builder environments.

The JSON import and section template strategy means we can build a layout or component once and deploy it consistently across Visual Composer and Elementor projects. This is a genuine production workflow improvement — not a theoretical architecture exercise. It directly reduces the time it takes to spin up new client sites and ensures visual consistency across projects.

What We Build and Who We Build It For

MarieHosting.com — Hosting for Creators and Businesses

Web hosting dashboard

MarieHosting — managed hosting built for people who need it to just work.

MarieHosting.com came out of a simple observation: most hosting providers are built for developers. The dashboards are technical, the support assumes knowledge, and the onboarding drops you into a wall of options with no clear path. We built MarieHosting for the other person — the business owner, the creative, the podcaster, the online radio station operator who needs hosting to work without needing to become a sysadmin.

Shoutcast streaming studio

Shoutcast and audio streaming hosting — a niche we understand deeply because we've run streaming infrastructure ourselves.

Our shoutcast and streaming hosting services are a particular area of expertise. We've run streaming infrastructure. We know what online radio station operators need, what breaks, what the common questions are, and what "it just needs to work" actually means in that context. That experience is baked into how we support streaming hosting clients.

BetterWebServices.com — Fiber, Connectivity, and Web Services

Professional web hosting server room

Enterprise-grade infrastructure supporting residential and small business clients.

BetterWebServices sits at the intersection of web services and physical connectivity. Our fiber optic internet services address a genuine gap — residential and small business clients who need better internet options than what the major carriers are prioritizing in their area.

Fiber optic cables Fiber installation

Fiber optic connectivity — fast, reliable, and increasingly essential.

Solar farm with internet tower

Connectivity solutions for rural and off-grid locations — including solar farm internet infrastructure.

Solar farm internet connectivity is an emerging area where we see significant opportunity. As renewable energy installations expand into rural and semi-rural areas, reliable internet infrastructure for those sites becomes a genuine need — for monitoring systems, operational management, and the people working there. BetterWebServices is positioned to serve that need.

Two Years of Honest Work — The Real Numbers

Here's where most rebuild stories end: the triumphant "we're back and better than ever" moment. The traffic graphs pointing up and to the right. The metrics that prove it was all worth it.

We're not going to do that. Because that's not where we are right now, and we think honesty serves you better than performance.

Two year journey timeline

Two years of continuous work. The timeline is real. The progress is real. The grind is real.

Two years into this rebuild, our Google organic traffic is growing — but slowly. We have 200 weekly search impressions across all four properties. If you've never been through a domain reset with Google, that number might sound alarming. If you have, you know exactly what phase of the process we're in.

Google Analytics dashboard

Real numbers. Real progress. Not where we want to be yet — but moving in the right direction.

When you reset a domain — even an old one with history — Google essentially re-evaluates everything. The trust signals that built up over years don't automatically transfer to new content. The algorithm has to re-learn what you are, who you're for, and whether you're worth surfacing. That process takes time. There's no shortcut. There's no hack. There's just consistent, quality work and patience.

What the data actually shows: BetterWebServices.com is appearing for 36 unique search queries — including "fiber optic installation" with 57 impressions this week alone. The content is being found and categorized correctly. The rankings will follow the authority. We're in the trust-building window, not the failure window. There's a difference.

SEO growth plant growing from keyboard

SEO after a domain reset is exactly like this. Slow, steady, organic. You cannot rush the roots.

"The content is being found. The rankings will follow the authority. We're in the trust-building window — not the failure window."

YouTube, TikTok, and Building Beyond Google

One of the hard lessons of the server failure and the Google reset is that any single point of dependence is a vulnerability. We've diversified.

Content creator workspace

Building a presence that doesn't depend entirely on Google to survive.

Our YouTube channel (solarblu seth) has 106 subscribers and continues to grow. Our TikTok account has 1,900 followers. These aren't vanity metrics to us — they represent an audience we've built directly, one that doesn't require a Google ranking to reach. That's valuable in a way that goes beyond the numbers.

The content strategy across YouTube and TikTok is evolving to support all four of our web properties — driving direct traffic, building brand recognition, and creating the kind of cross-platform presence that strengthens everything else. When someone finds us on TikTok and then visits solarblu.net, that's a traffic signal Google notices. The platforms reinforce each other.

What We've Actually Learned

Back up everything. Redundantly. Off-site.

This is obvious in retrospect and easy to defer in practice. We deferred it. Don't. A daily automated backup to a location that is physically and logically separate from your server is not optional infrastructure — it's the minimum viable safety net for anything you care about.

Build on maintained foundations, not custom everything.

Custom themes are beautiful until they're a liability. Astra plus a well-structured plugin for your custom layer gives you 90% of the control with 10% of the maintenance burden. The remaining 10% of control you give up is almost always control you didn't need.

PHP version compatibility is a real project, not a checkbox.

Plan for it. Budget time for it. And when the migration cost exceeds the value of the legacy code, retire the legacy code. That's not failure — that's engineering judgment.

Google resets are survivable — but they require patience.

The impressions come before the clicks. The clicks come before the rankings. The rankings come before the traffic. You will go through all of these phases in order, and there is no phase you can skip. Do the work, publish consistently, build links where you can, and wait. It works. It just works slowly.

Diversify your traffic sources from day one.

Don't wait until Google disappoints you to build your social presence, your email list, your YouTube channel. Build them in parallel. They will save you during the phases when organic search feels like shouting into a void.

Where We Go From Here

SolarBlu brand concept

Two years in. Still building. Still here. Just getting started.

We're proud of what's been built. Not in a polished, everything-went-perfectly way — in the real way, where you've been through something hard and come out the other side with something that actually works and something you actually understand down to its foundations.

Four websites rebuilt on a clean, modern, PHP 8.3-compatible stack. A plugin in active development that's growing into something genuinely useful. Hosting services running on infrastructure we trust. Fiber connectivity services addressing a real gap. A content presence across YouTube and TikTok that doesn't depend on Google's good graces to reach an audience.

The hard drive that started all of this still sits on our desk. We kept it — not as a monument to disaster, but as a reminder that sometimes the thing that breaks everything is also the thing that makes you build something better.

The server room is quieter now. The work is not.

"Sometimes the thing that breaks everything is also the thing that makes you build something better."

If you're going through a similar rebuild — domain reset, server failure, platform migration, or just the slow grind of building web properties that Google hasn't warmed up to yet — we'd genuinely love to hear from you. This story isn't finished, and we don't think yours is either. Reach out through any of our properties. We're building in public, and we're happy to compare notes.

WordPress Web Hosting PHP 8 Server Failure Domain Reset SEO Recovery Astra Theme Advanced Themer Elementor Visual Composer Fiber Internet MarieHosting BetterWebServices SolarBlu solarbluseth Web Development Rebuild Story
Self-Hosted AI

When Your AI Agent Goes Dark: Removing the External Drive Dependency from OpenClaw

📡 Celeste Field Update — April 2026

When Your AI Agent Goes Dark: Removing the External Drive Dependency from OpenClaw

Sunday morning. Coffee in hand. Check on Celeste. She's offline. Not because the Pi crashed. Not because the internet went down. Because a USB external drive I'd been meaning to remove for weeks quietly unmounted itself, and with it went every npm global package OpenClaw needed to run — including OpenClaw itself. This is the story of how one external drive nearly took out my 24/7 AI assistant, and how we cleaned it up for good.

How We Got Here

A while back, during the great npm-global migration project, I moved my npm global package directory to an external USB drive called sethdisk1. The reasoning made sense at the time — free up space on the SD card. The problem is that npm doesn't just store packages on that drive. It stores the entire runtime dependency chain for every globally installed tool. Including OpenClaw. So when sethdisk1 decided it was done mounting at boot, OpenClaw's systemd service kept trying to launch a binary that pointed here:
/media/admin/sethdisk1/npm-global/lib/node_modules/openclaw/openclaw.mjs
File not found. Service crash. Restart in 10 seconds. File not found. Repeat, forever, until the restart counter hit its limit and systemd just gave up.
⚠️ Lesson Learned Never set your npm global prefix to an external drive that isn't guaranteed to be mounted before your services start. If you need overflow storage, handle it at the OS level with fstab and RequiresMountsFor= in your systemd unit — not by pointing npm at it.

The Diagnosis: Reading the Logs

The first thing that tipped us off was the missing systemd service file entirely. After a reboot the service unit was gone — likely a casualty of an earlier interrupted update. Once we recreated the service and tried to start it, journalctl told the real story:
Error: Cannot find module '/media/admin/sethdisk1/npm-global/lib/node_modules/openclaw/openclaw.mjs'
code: 'MODULE_NOT_FOUND'
Node.js v22.22.2
The drive wasn't mounted. The files weren't there. And we'd already decided we wanted to remove the drive entirely — so this was actually the perfect forcing function to finally do it right.

The Fix: Cutting the Drive Dependency

Here's the sequence that worked. The goal was to get npm pointing entirely at local storage and get OpenClaw reinstalled clean.

Step 1 — Stop the restart loop

sudo systemctl stop openclaw
sudo systemctl disable openclaw

Step 2 — Fix npm's global prefix and cache

Both were pointing at the external drive. Fix them both:
npm config set prefix '/home/admin/.npm-global'
npm config set cache '/home/admin/.npm-cache'
echo 'export PATH=/home/admin/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc
Verify they took:
npm config get prefix
npm config get cache

Step 3 — Clear the broken partial install

There was a half-copied openclaw directory from an earlier failed migration attempt — it had dist/ and node_modules/ but was missing package.json and the bin symlink. Useless. Remove it:
rm -rf /home/admin/.npm-global/lib/node_modules/openclaw

Step 4 — Reinstall via the official installer

npm on a Pi 4 is painfully slow for large installs. We skipped the npm route entirely and used the official curl installer instead:
curl -fsSL https://openclaw.ai/install.sh | bash
This is actually the recommended method for Raspberry Pi — it handles Node detection, sets up the correct paths, and runs the onboarding wizard. Much faster than waiting for npm to resolve dependencies on ARM hardware.

Step 5 — Recreate the systemd service

sudo nano /etc/systemd/system/openclaw.service
[Unit]
Description=OpenClaw AI Agent Service
After=network.target

[Service]
Type=simple
User=admin
WorkingDirectory=/home/admin/.openclaw
ExecStart=/home/admin/.npm-global/bin/openclaw --config /home/admin/.openclaw/openclaw.json
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw

The Timeline of This Morning

Morning

Celeste goes dark

Checked Discord — no response. Pi is up, network is fine. OpenClaw service is missing entirely.
+15 min

Service file gone, binary found at /usr/bin/openclaw

Recreated the service file. Started it. Immediate crash loop. Journalctl reveals the MODULE_NOT_FOUND error pointing to the unmounted drive.
+30 min

Drive is already unmounted/gone

du on the drive path returns nothing. Decision made: remove the drive dependency entirely.
+45 min

npm cache also pointing to dead drive

Running npm show openclaw fails with EACCES trying to write to the drive cache path. Fixed both prefix and cache.
+60 min

Partial install discovered, npm reinstall attempted

Openclaw directory exists but is broken — missing package.json and bin symlink. npm install starts but grinds. Switched to curl installer.
+75 min

Celeste back online

Clean install, service recreated, config intact. All 185 skills preserved. Kimi K2.5 backend reconnected.

What Celeste's Config Survived

The good news in all of this: your ~/.openclaw/ directory is completely separate from the npm installation. All of this survived untouched:
  • All 185 skills
  • The full openclaw.json config (plus several dated backups)
  • Agent memory, tasks, flows, and workspace files
  • Discord channel integration (channel ID intact)
  • Kimi K2.5 backend configuration via Moonshot AI
OpenClaw stores its runtime data completely separately from its binary installation. This is actually good design — it means reinstalls are safe and non-destructive. The frustration comes entirely from npm's global path configuration, not from OpenClaw itself.
✅ Pro Tip OpenClaw auto-creates timestamped backups of your config: openclaw.json.bak.20260412, openclaw.json.backup.20260327-131114, etc. These are in ~/.openclaw/. If something ever goes wrong with a config update, you can restore from any of these instantly.

Why npm on Pi Is a Pain (And What to Do About It)

This isn't the first time we've hit npm slowness on the Pi 4. It's a known issue — npm's dependency resolution is CPU-intensive, and ARM processors don't have the raw compute that x86 does. A package that installs in 30 seconds on your desktop can take 10+ minutes on a Pi 4. A few things that help:
  • Use the curl installer for OpenClaw specifically — it's optimized for Pi and skips a lot of the npm overhead
  • Add a NODE_COMPILE_CACHE environment variable to speed up repeated invocations: export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Never put npm-global on an external drive unless you absolutely have to, and if you do, make sure the drive auto-mounts before services start via /etc/fstab
  • Keep swap active — the Pi 4 default 100MB swap is not enough. Set it to at least 1GB

Current State of the Machine

After this morning's cleanup, here's where things stand :

mrk-pi4 Status — April 12, 2026

  • Hardware: Raspberry Pi 4 Model B Rev 1.5, 7.6GB RAM
  • OS: Raspberry Pi OS 64-bit (aarch64, kernel 6.1.21)
  • Storage: 27GB root, 2.8GB free (external drive removed)
  • OpenClaw: Reinstalled clean via curl installer
  • Celeste config: Intact — 185 skills, all data preserved
  • Backend: Moonshot AI / Kimi K2.5
  • Discord: Reconnected, private #sethbot channel active
  • npm paths: Now 100% local — no external drive dependency

What's Next

The external drive removal was overdue. Now that npm is fully local and the service file is clean, the Pi 4 is actually in its most stable state since we started this project. A few things on the roadmap:
  • SD card upgrade — still running close to capacity. A 512GB A2-rated card is on the list for a clean clone and expansion.
  • Aaron agent — a second OpenClaw instance on a private VPS, positioned as a junior admin/support agent. Different model, stripped skill set, separate from Celeste's environment.
  • Auto-mount safety net — documenting the proper /etc/fstab + systemd RequiresMountsFor= pattern for anyone running OpenClaw with external storage, so nobody else hits this same wall.
The Pi 4 keeps proving itself. It's not glamorous hardware — no NVMe, no PCIe, slower than the Pi 5 — but with 7.6GB RAM and a cloud backend doing the heavy inference work, it handles everything Celeste needs to do. Low power, always on, sitting quietly in the corner doing its job. Until the USB drive unmounts itself. But we fixed that.

Links and Resources

Self-Hosted AI

The Celeste Chronicales April 2026

The Celeste Chronicles — April 2026

72 Hours of Chaos, Upgrades & Lessons Learned

Upgrading the Pi, installing a LAMP stack, surviving multiple OpenClaw config meltdowns, and getting Celeste back online — a brutally honest field report from the lab at SolarBlu HQ.

If you've been following the Celeste build series, you know that running a self-hosted AI agent on a Raspberry Pi is one of the most rewarding — and occasionally maddening — things you can do as a developer. The last 72 hours have been a masterclass in "what can go wrong, will go wrong." But also: what gets fixed, gets faster. Here's the full play-by-play.
3x OpenClaw upgrades
PHP 8 LAMP stack installed
185+ Celeste skills active

The Raspberry Pi Upgrade (That Nobody Planned)

The short version: the Pi needed to come up to speed. We'd been running on a configuration that was starting to show its age — tighter disk space, slower package management, and a slow external USB drive that turned out to be causing more grief than we realized. The decision was made to do a full OS upgrade (Bullseye → Bookworm) and move some key directories off the external drive. The upgrade process itself was textbook Debian — painfully slow but stable. With 1,478 packages to pull down and update, we were looking at 20–40 minutes of sitting on our hands while the progress bar crawled across the screen. The key lesson here: don't interrupt a dist-upgrade mid-stream. We didn't, and it paid off.
⚠ Heads Up If you're running OpenClaw's npm global install on an external USB drive, be aware that permission errors and filesystem quirks (like the ENOTEMPTY npm bug) are significantly more likely. Moving npm-global to the Pi's internal storage reduced our headaches considerably.

The Disk Space Trap

We ran out of disk space mid-session — one of those classic "oh no" moments where you realize the external drive that seemed like a great idea is now the bottleneck for everything. The fix was clearing the npm cache and relocating the global install directory. Once that resolved, performance improved noticeably across the board. The Pi stopped feeling sluggish. Celeste's responses got snappier. Lesson learned: keep your AI agent's core files on fast internal storage.

Building the LAMP Stack for PHP Dev Work

One of the new additions this week: a full LAMP stack on the Pi, set up specifically for PHP 5.3 → PHP 8 conversion work and WordPress theme/plugin testing. The goal is to use the Pi as a local dev environment — build and test locally, then FTP the finished product to client servers. The install is straightforward on Bookworm:
sudo apt update
sudo apt install apache2 php php-mysql php-curl php-gd \
  php-mbstring php-xml php-zip mariadb-server phpmyadmin \
  php-imagick php-intl -y
MariaDB is the drop-in MySQL replacement used on Pi/Debian — works identically for WordPress and most PHP applications. For the PHP version switching needed in 5.x → 8.x migration work, update-alternatives lets you flip between installed PHP versions per project.

Why This Matters for the Workflow

Here's the practical upside: Celeste now has a local WordPress environment to interact with. Long-term this means she'll be able to draft posts, test theme changes, and preview landing pages — all on the Pi — before anything touches a live server. Combined with WP-CLI and an FTP client like lftp, this creates a tight local-to-production pipeline that doesn't require touching a paid hosting environment for every iteration.
✓ Stack Installed Apache2 + PHP 8 + MariaDB + phpMyAdmin running on the Pi, accessible on the LAN for local WordPress development and PHP compatibility testing.

The OpenClaw Config Wars

Here's the part nobody warns you about loudly enough in the documentation: OpenClaw updates frequently, and it breaks configs without mercy. In the last 72 hours alone we went through three separate upgrades — and each one required config surgery. The specific error that brought everything down this time:
channels.discord.streaming: Invalid input
(allowed: true, false, "off", "partial", "block", "progress")
Sounds simple. Wasn't. The config had the streaming value set as a JSON object {"mode": "off"} rather than the plain string "off" that a newer version of OpenClaw expected. Then a subsequent manual edit accidentally set it to the string "false" (with quotes) instead of the boolean false. Each fix had to be verified by reading the actual file on disk — not trusting what was shown in the UI.
  • Problem 1 Streaming value was an object, not a string "streaming": {"mode": "off"} → needed to be "streaming": "off"
  • Problem 2 String "false" vs boolean false Edited to "streaming": "false" (string) — still invalid. Needed false with no quotes.
  • Problem 3 Python fix wrote to wrong path Script used /root/ path but config lived at /home/admin/ — file never got updated.
  • Resolution Direct Python fix to correct absolute path python3 script targeting /home/admin/.openclaw/openclaw.json, setting streaming to Python False (serializes as JSON boolean false).
The service was stuck in a restart loop — 82+ failed restarts before we got the right fix in. The key diagnostic command that saved us:
sudo journalctl -u openclaw -n 100 --no-pager

⚡ Hard-Won Lessons: OpenClaw Config Management

  • Back up before every upgrade. The ~/.openclaw/backups/ folder exists for a reason. Copy it somewhere safe before running npm install -g openclaw.
  • Old config files don't carry forward cleanly. Each major version can deprecate or change field types. Don't assume your working config from last week still validates on the new version.
  • Run openclaw doctor --fix after every upgrade — not just when something breaks. It catches schema mismatches before they become restart loops.
  • Know where your config actually lives. If you're running as a different user than you think, your Python/bash fix might be editing the wrong file. Always verify with find / -name "openclaw.json".
  • The external drive was part of the problem. I/O slowdowns from a slow USB drive can cause the OpenBoard GUI to hang and the onboarding wizard to stall — symptoms that look like software bugs but are actually hardware throughput issues.

When to Just Nuke It and Start Fresh

There comes a point in any debugging session where the accumulated state of a broken install becomes harder to fix than a clean reinstall. We hit that point. The npm global directory on the external drive had corrupted symlinks, the ENOTEMPTY error was blocking normal uninstall, and even sudo rm -rf couldn't remove a nested ARM binary package. The process that eventually worked:
# Stop the service first
sudo systemctl stop openclaw

# Find what's holding the directory open
lsof +D /path/to/openclaw/node_modules

# Kill any lingering processes
sudo pkill -f openclaw

# Force remove the stuck directory
sudo rm -rf /media/admin/sethdisk1/npm-global/lib/node_modules/openclaw

# Fresh install
npm install -g openclaw
"The anticipation of watching npm install hundreds of packages one by one is genuinely its own kind of suspense. But a clean install after a corrupted one feels like rebooting your whole day."
After the fresh install completed, OpenClaw came back up cleanly. The gateway bound to the LAN interface, the OpenBoard GUI loaded, and Celeste was back online. The performance improvement from having the install on internal storage (vs. the slow external drive) was immediately noticeable.

Where Celeste Stands Now

After 72 hours of upgrades, debugging, and infrastructure work, here's the current state of the lab:
Pi 4 8GB RAM, Bookworm OS
2026 .4.10 OpenClaw version
LAMP PHP 8 + MariaDB live
24/7 Discord integration
Celeste is running on Kimi K2.5 (Moonshot AI) as the primary backend, with Claude Sonnet 4 and GPT-5 Nano as fallbacks. The Discord gateway is live on the private #sethbot channel. The LAMP stack is ready for PHP development work. And the systemd service brings everything back automatically after reboots. The multi-provider model config means if Kimi runs out of API credits or has an outage, Celeste automatically falls through to the next provider. No babysitting required.
 
SolarBlu
Scroll to Top