Self-hosted agent implementation · live service
OpenClaw & Hermes Client Deployments
A client implementation service for turning OpenClaw or Hermes into a secure, self-hosted operating agent: workflow discovery, infrastructure provisioning, Docker isolation, credentials, integrations, acceptance testing, and controlled handoff.
The service runs on client-owned infrastructure. Provider availability and exact integrations depend on each customer's environment and permissions.
6
named productivity and communication integrations
14 days
post-launch support included
1
client-owned deployment boundary
0
implementation access retained after handoff
The system
From operational problem to reliable workflow.
Problem
Installing an open-source agent is only the first step. A useful production deployment must reconcile host security, Docker isolation, OAuth and API permissions, multiple communication channels, credential custody, workflow-specific behavior, and a handoff that leaves the client in control.
Approach
The service starts with workflow discovery, selects OpenClaw or Hermes for the operating requirements, deploys on infrastructure owned by the client, hardens the host and runtime boundary, configures each provider independently, tests real end-to-end scenarios, and transfers operational control.
Outcome
Clients receive a self-hosted agent connected to the tools they actually use, with documented ownership of infrastructure and credentials, an explicit security boundary, verified workflows, and a support path for the first production edge cases.
Architecture
System architecture
OpenClaw Setup is the public service surface for Harshitha's OpenClaw and Hermes implementations. The engineering work is not merely launching a container: it is selecting the right runtime, creating a bounded operating environment, assigning minimum necessary provider permissions, connecting communication surfaces, translating a client's recurring work into testable behaviors, and transferring control without leaving a hidden dependency on the implementer.
Discovery and acceptance layer
Turns loosely described work such as email triage or meeting preparation into named channels, required permissions, expected outputs, escalation rules, and pass/fail scenarios.
Workflow mapping · acceptance criteria · human review rules
Client-owned host
Provides the durable compute and storage boundary on a VPS, Mac mini, or Linux server controlled by the client rather than a shared service account.
Linux · VPS or Mac mini · SSH
Sandboxed agent runtime
Runs OpenClaw or Hermes inside an isolated boundary and limits host exposure through firewall rules, hardened remote access, and deliberate filesystem or service access.
OpenClaw · Hermes · Docker · firewall hardening
Credential and permission boundary
Stores provider credentials outside public code, scopes OAuth/API access to the requested jobs, and returns custody entirely to the client after implementation.
Encrypted secrets · OAuth · provider API keys
Channel and productivity adapters
Connects the agent to email, calendar, team chat, mobile messaging, and knowledge tools while testing each provider's authentication and behavior independently.
Gmail · Calendar · Slack · WhatsApp · Telegram · Notion
Service and acquisition surface
Explains scope, captures bookings, publishes implementation guidance, and deploys as a static web surface independent from client agent runtimes.
Next.js · Azure Static Web Apps · custom DNS · Cal.com
Execution model
End-to-end execution
- 01
Define the operating job
Harshitha identifies the recurring work, systems involved, acceptable autonomous behavior, actions that require review, and observable acceptance criteria.
- 02
Provision the ownership boundary
The agent is installed on a client-owned VPS, Mac mini, or Linux host so infrastructure, data, and shutdown authority remain with the customer.
- 03
Harden and isolate the runtime
Docker isolation, firewall rules, SSH controls, and encrypted credential handling are configured before production integrations are enabled.
- 04
Connect providers one by one
Gmail, Calendar, Slack, WhatsApp, Telegram, and Notion are authorized and validated as independent integrations with distinct permissions and failure behavior.
- 05
Exercise real workflows
Representative inbox, calendar, messaging, and knowledge scenarios are executed end to end, including escalation and human-review paths rather than only connection tests.
- 06
Transfer and stabilize
The client receives operational ownership, implementation access is removed, and the first production edge cases are handled during a 14-day support period.
Implementation
What Harshitha implemented
- Converted customer goals into a deployment checklist covering hosts, accounts, channels, permissions, expected agent behavior, human review, and acceptance tests.
- Structured the installation around a client-owned host instead of a shared black-box SaaS environment.
- Selects OpenClaw or Hermes according to the client's channel, workflow, tool, and runtime requirements instead of forcing every deployment into one agent framework.
- Applied Docker sandboxing, firewall restrictions, SSH hardening, and encrypted credential storage as baseline deployment work rather than optional follow-up security.
- Configured and separately validated Gmail, Google Calendar, Slack, WhatsApp, Telegram, and Notion integration paths.
- Tested real operational scenarios and tuned the agent around expected actions, escalation behavior, and user-facing outputs.
- Designed the handoff so the customer owns infrastructure and credentials and implementation access can be removed after setup.
- Operates the public service surface used for positioning, booking, expectation-setting, and post-launch support.
Contribution summary
- Owns the public client implementation surface and works directly with customers from workflow discovery through deployment, testing, handoff, and support.
- Maps requested outcomes—such as inbox triage, calendar coordination, Slack monitoring, or mobile agent access—into integrations, permissions, triggers, and acceptance checks.
- Applies deployment controls around Docker isolation, firewall and SSH hardening, encrypted credential storage, and removal of implementation access after handoff.
- Validates Gmail, Calendar, Slack, WhatsApp, Telegram, and Notion connections as separate failure domains instead of treating one successful login as a complete deployment.
- Maintains the service experience around booking, implementation scope, technical expectations, ownership, and 14-day post-launch support.
Failure design
Reliability engineering
R01
Risk
A successful installation is mistaken for a working business workflow.
Control
Acceptance checks exercise complete email, calendar, messaging, and knowledge scenarios with expected outcomes and review points.
R02
Risk
An OAuth token is over-scoped or one provider silently fails.
Control
Each integration is authorized and tested independently with only the permissions required for the agreed workflow.
R03
Risk
The agent can reach more of the host than the job requires.
Control
Docker isolation, firewall rules, hardened SSH, and deliberate host access reduce the blast radius of the runtime.
R04
Risk
The implementer remains an undisclosed dependency after launch.
Control
Infrastructure and credentials stay client-owned, implementation access is removed, and ownership is made explicit during handoff.
R05
Risk
Edge cases appear only after the agent meets real traffic.
Control
A 14-day stabilization window covers early workflow tuning and failures that cannot be reproduced in a one-session setup test.
Tradeoffs
Technical decisions
Deploy into the client's infrastructure
Client ownership reduces platform lock-in, keeps operational data inside an explicit boundary, and gives the customer final control over access and shutdown.
Harden before connecting business accounts
Security controls are most effective when they define the runtime from the start, before email, messages, calendars, or credentials enter the system.
Test workflows, not just integrations
A green OAuth callback proves connectivity, not that an agent handles ambiguity, review, and escalation correctly in the client's operating context.
Keep the marketing site separate from agent runtimes
A static Azure-hosted acquisition surface can change or deploy without sharing code, secrets, or failure modes with any customer's agent environment.
Credibility
Evidence and scope
Live service surface
The public site documents the deployment scope, Docker and host hardening, supported integration categories, client ownership model, booking path, and support window.
Production web delivery
The Next.js acquisition surface is statically exported to Azure Static Web Apps on the custom domain, with DNS, booking, analytics, blog, and structured metadata separated from client runtime infrastructure.
Named operator responsibility
Harshitha is publicly identified as the AI product engineer clients work with directly across discovery, setup, validation, handoff, and support.
Attribution boundary
This case study covers Harshitha's current responsibility as the client-facing implementation operator for OpenClaw Setup and Hermes deployments: workflow discovery, runtime selection, secure deployment, integration validation, handoff, and support. Service delivery is distinguished from authorship of the upstream OpenClaw or Hermes projects.
Technology