Most of us who run an agency have lived the same story. We start on whatever hosting is cheap and easy, stack on a few client sites, and keep going until the cracks show. Then we spend more time fixing hosting problems than building pages, improving conversions, or supporting customers.

In this episode of Manana No Mas!, we talk with Jim Hankins about CribOps, an agency-only hosting platform he built after years of dealing with the same operational headaches agencies face every week. We cover what pushed him to build it, what it does differently (databases, caching, monitoring, media handling), and how it’s meant to fit into an agency workflow, not a hobby site.

Why Jim Hankins built CribOps for agencies (and not for everyone)

Jim Hankins didn’t come to “WordPress hosting” from a typical path. He runs an agency called Cloud Beerrock, but his foundation is deep in IT operations and backend work, including time at Cisco and long-term work supporting large automotive environments. That background shows up in what he worries about first: uptime, data loss, recovery options, and the “blast radius” when one thing fails.

He also has experience as a CTO building infrastructure for emergency response coordination tied to panic devices. When someone hits an SOS button off-grid, the backend systems have to receive the signal, route it correctly, and support the response center so help can be dispatched. That type of work shapes how we think about hosting for agencies, because it’s not about pretty dashboards first. It’s about systems that don’t crumble when something goes wrong.

A key part of Jim’s story is that he’s had successful exits, including a company acquired by Garmin. That gave him the space to focus on building products around real operational needs he saw in his agency work.

CribOps is positioned as an agency product, not a general consumer host. The point is to help agencies standardize how sites are deployed, monitored, and supported, so we spend less time putting out fires and more time delivering outcomes for clients. Jim’s north star is simple: agencies need more control than most managed hosts allow, but they also need fewer fragile “DIY stacks” that turn into support nightmares.

The “Heck with it, we’ll build it” moment

CribOps came from a familiar agency impulse: we get tired of repeating the same fixes across different clients, different hosts, and different setups. Jim described trying other tools first, looking for something that fit the way his agency works. When none of them did, he chose to build what he wanted to use himself.

It also started as a practical family business problem. Jim works with his wife and son in the agency, and he wanted a hosting environment where the day-to-day support work didn’t bottleneck on the one “IT person” who knows how to diagnose server issues. In agency terms, it’s the difference between “everything becomes a ticket” and “we can solve common issues fast, with guardrails.”

That’s the angle we appreciated most. CribOps isn’t pitched as a hobbyist playground. It’s aimed at agencies that need repeatability, a clear support posture, and fewer surprises.

We’ve all met the client who watches one YouTube video and installs three “performance” plugins, then wonders why checkouts break. Jim’s approach is to reduce the number of ways a site can be accidentally broken, while still giving agencies the visibility and controls they need when something serious happens.

The agency hosting problems we keep seeing (and why they don’t go away)

In the episode, we talked about the messy reality of agency hosting choices. Many of us have used shared hosting early on, then moved to VPS platforms, then tried premium managed WordPress hosts. The names change, but the pattern stays the same: once clients rely on the site for revenue, “mostly works” isn’t good enough.

Two pain points came up repeatedly.

First, lack of access and slow troubleshooting. Some hosts lock things down so tightly that we can’t even check what we need to check without opening a ticket. When we’re trying to solve a client problem in real time, waiting on someone else to pull logs or confirm a server-side setting creates delays and stress.

Second, tool sprawl and clunky workflows. Even hosts that provide agency features sometimes bury them in interfaces that feel dated or confusing for end customers. Agencies end up building custom sales pages and handling provisioning manually because the host’s reseller flow doesn’t match how clients buy. That’s time we could spend on delivery.

We also see a market shift: clients increasingly ask for more than “a WordPress site.” They want a static front end, a headless build, a small app, or an automation tool that sits next to their site. Even when WordPress remains the core, agencies get pressure to support “one more thing,” which can turn into multiple hosting accounts and scattered infrastructure.

Caching confusion gets expensive fast, especially for LMS sites

Caching came up as one of the most common sources of “it looks broken” support tickets. Page caching is often the culprit, especially on sites with dynamic content like checkouts, logins, course dashboards, certificates, and membership access rules.

We see this a lot in e-learning. LifterLMS sites are not brochure sites. They involve user accounts, enrollments, quizzes, progress tracking, certificates and achievements, membership rules, and paid access plans that can be one-time or recurring. Those moving parts mean the site must serve the right content to the right logged-in learner at the right moment. When aggressive caching serves the wrong version of a page, users can get locked out, see missing content, or think their account doesn’t exist.

This also spills into payments and automation. Many LifterLMS builds rely on payment gateways, subscriptions, and integrations, plus email and notification workflows. When caching masks state changes, the result is confusion at best and lost revenue at worst.

Jim drew a clear line between page caching and object caching. Page caching can cause trouble when it’s applied to pages that should always be dynamic. Object caching, when implemented correctly, can speed up database-driven operations without serving stale full-page output.

For a grounded baseline on hosting considerations for this kind of site, we recommend reviewing the LifterLMS hosting guide. It frames the hosting decision around student experience and reliability, which is exactly where agencies get judged.

What CribOps does differently (features tied to agency outcomes)

CribOps is built around a few strong opinions that map closely to agency pain.

Managed databases with point-in-time recovery, not “hope the daily backup works.”

One of Jim’s biggest design choices is avoiding the classic “everything on one VPS” setup. When multiple client sites share a single server and that server also holds the database, we create a large failure domain. If the server fails, a lot fails at once. If a database gets corrupted or a plugin writes bad data, “restore last night’s backup” might still mean losing hours of orders, enrollments, or membership changes.

CribOps uses a managed database approach, including a primary and secondary setup, and supports point-in-time recovery. In practical terms, that means we can restore to a specific minute, not just “yesterday.” If a WooCommerce store or an LMS site gets damaged by a bad update or a misguided direct database change, that recovery window matters.

This is the part that felt most “enterprise-minded” in the conversation. We’re not talking about theoretical edge cases. Agencies see real incidents: a client runs a sale, orders come in, then something breaks. If we can’t recover recent data cleanly, we own the fallout.

Object caching by default, without forcing page caching on dynamic sites

CribOps includes object caching on every site, using Redis-compatible technology. The aim is better performance where it counts for logged-in experiences, including WordPress admin work and plugin-heavy sites like LifterLMS.

This matters because many agencies try to solve speed issues by stacking plugins. One host provides a cache plugin, then a theme adds optimization, then a third plugin adds “performance,” and soon we’ve got multiple tools fighting each other. The site becomes unpredictable, and support turns into detective work.

Jim’s stance is to avoid default page caching because page caching can break dynamic flows if it’s applied carelessly. Instead, the platform focuses on real user experience over chasing scores.

If you want to understand why Redis-style caching is often used for reliability and performance in distributed setups, Redis documents the concept well in its guide to highly available applications with Redis.

Multi-type hosting in one agency account (WordPress plus static and app workloads)

CribOps isn’t trying to be “WordPress-only forever.” Jim described supporting multiple types of sites within the same agency platform:

• WordPress sites, including a mode that can be configured as mutable or immutable (more on that below)
• Other web runtimes like PHP and Laravel
• Node.js deployments
• Static hosting for modern “vibe-coded” builds (Lovable, Bolt, Claude-style workflows were mentioned)
• Self-hosted n8n as an option

The agency benefit is fewer scattered accounts and fewer isolated systems. If a static front end still needs a database, Jim’s idea is that it should be able to use the same underlying database service rather than forcing an agency to stitch together five vendors.

He also talked about containers and per-site resource tuning, so an agency can give one client more CPU or memory when a promotion hits, without redesigning the whole server plan. That matches how traffic behaves in real agency portfolios: most sites are quiet, a few are seasonal, and a small number drive the support load at the worst possible times.

CribOps also supports per-site storage allocation, with a default per site and the ability to grow it. That matters for media-heavy course sites.

How CribOps fits into day-to-day agency work

A control panel plus a mobile app, with alerts that matter

CribOps includes its own control panel, plus a mobile app that mirrors the same view. The mobile piece isn’t a gimmick in Jim’s description. It’s meant for quick response: see when a site is down, get notified, and take action.

One example was monitoring for “white screen of death” scenarios, not just simple up/down checks. If the monitoring detects a failure state, the app can push a notification, and the agency can jump straight into remediation steps like restarting.

That lines up with how agencies actually operate. Clients don’t call when everything is fine. They call when a checkout fails, an LMS login breaks, or a landing page stops loading right before a campaign. Faster visibility reduces panic.

Jim also discussed scoping access through a multi-tenant model. The system can be configured so an end customer only sees their own site. Whether an agency wants to expose that is a separate question, because it brings branding and support expectations along with it.

Client access, plugin control, and support boundaries

Jim’s support philosophy will feel familiar to many agency owners. Most clients don’t want to be webmasters. They want results. For that majority, CribOps can support a locked-down model where users can log in, but don’t have the ability to install or update plugins. Jim said this covers the vast majority of cases.

For the small percentage of clients who want to go off-standard (new themes, custom plugins, a different LMS, third-party devs), his approach is clear: it’s allowed, but the support burden shifts. The agency can still help recover from backups, but the client owns the consequences of changes outside the standard stack.

We also discussed standardizing on LifterLMS in his agency, which makes sense if your agency specializes in memberships and courses. LifterLMS has a wide feature set (courses, memberships, quizzes, engagements like certificates and emails, and payments), and standardization reduces the number of variables when troubleshooting. When we choose a primary LMS and stick to it, we build depth faster, and clients get better outcomes.

For more context on the show and future episodes, visit the Manana No Mas! site.

Migration, pricing, and who CribOps is built for

CribOps is positioned as agency-only, with pricing structured around agency tiers. Jim mentioned a starting tier that includes 20 sites, with the reality that one client could consume a large share of resources if needed. The platform is designed so agencies can tune resources per site, including setting limits to avoid noisy neighbor problems.

Migration is part of the offer. Jim described server-to-server migrations that don’t require installing a plugin, including planned automation from sources like cPanel and GridPane. The goal is to move sites with less manual work and less risk, especially for agencies managing many installs.

That matters because migrations are where “cheap hosting decisions” get expensive. Every manual step adds time, risk, and client communication. Automated paths reduce that load.

CribOps seems best suited for agencies that:

• Manage a portfolio of client sites, including LMS and e-commerce builds
• Want more operational control without running everything on a single VPS
• Need a stable approach to caching and performance for logged-in users
• Expect to support more than WordPress over time (static apps, headless builds, automations)

If you want to explore the platform directly, start at CribOps agency hosting.

Lerty: an AI automation product Jim is also building

Jim also shared a second product he’s involved with: Lerty, an automation tool designed for people building and running AI agents. The use case is straightforward. If we’ve built automations in tools like n8n, Zapier, or Make, we often reach a point where we want to package that work into something we can sell, or at least use consistently as our “second brain.”

Lerty is positioned to help with both. Jim described tiers that include a free plan, a $29 per month plan, and a higher-priced agency tier for teams that want to sell agent-based services.

This fits the same theme as CribOps: agencies want repeatable systems that reduce custom one-off chaos. We can build an automation once, then offer it in a structured way, rather than rebuilding and re-explaining the same setup per client.

If that’s relevant to your agency roadmap, see Lerty AI automation tools.

Conclusion: hosting is an agency operations decision, not a “server choice”

CribOps is interesting because it treats hosting like agency infrastructure, not a commodity. The focus stays on fault tolerance, recovery options, and sane defaults for dynamic sites that can’t afford caching mistakes.

If we’re tired of juggling multiple vendors, fighting plugin stacks, and praying that last night’s backup is good enough, this episode is a useful listen. We can explore CribOps agency hosting and decide if its approach matches how we want to run operations, then keep an eye on Lerty if AI agents are becoming part of our service offering.