Enterprise: Self-Hosted Deployment

Introduction to Self-Hosted Deployment

Hopsule Enterprise offers a self-hosted deployment model designed for organizations that require absolute data sovereignty and complete control over their decision-making infrastructure. In this model, the entire Hopsule ecosystem—including the Hopsule Dashboard, the Knowledge Graph, and the Hopsule API—is deployed within your own private cloud or on-premise data center. This ensures that your team’s most sensitive organizational judgment, historical memories, and enforceable decisions never leave your controlled environment.

By choosing a self-hosted deployment, engineering organizations can align their context preservation strategies with strict internal security policies and regulatory requirements. Whether you are operating in a highly regulated industry like finance or healthcare, or simply managing a large-scale engineering team where intellectual property protection is paramount, the self-hosted option provides the highest level of assurance that your organizational memory remains your own. Hopsule is not merely a utility; it is a governance layer, and the self-hosted model ensures that this layer is as secure as the code it governs.

Strategic Rationale for Self-Hosting

The decision to self-host Hopsule is often driven by the need for rigorous data governance and the preservation of context in environments where external data transmission is restricted. Organizations that utilize Context Packs and Capsules to manage high-stakes engineering decisions require a platform that mirrors their own infrastructure's security posture. Self-hosting eliminates the reliance on third-party cloud availability and places the authority over the data lifecycle entirely in the hands of the customer.

Furthermore, self-hosted environments allow for deeper integration with internal identity providers and security monitoring tools. For teams utilizing Hopsule MCP to connect AI agents to their internal decision history, a self-hosted deployment ensures that these agents are interacting with a context layer that is physically and logically isolated from the public internet. This architecture supports the Hopsule philosophy that enforcement is remembrance, not control, by allowing the organization to define the boundaries of that remembrance.

Deployment Architecture and Options

Hopsule Enterprise is delivered as a suite of containerized services designed to be orchestrated within your existing infrastructure. The architecture is modular, allowing for scaling of specific components like the Hopsule API or the Knowledge Graph processing engine based on the volume of decisions and memories being managed. This modularity ensures that the Hopsule Dashboard remains responsive even as the complexity of your organizational memory grows.

Organizations have two primary paths for self-hosted deployment:

• Private Cloud Deployment: Deploying Hopsule within a virtual private cloud (VPC) on providers such as AWS, GCP, or Azure. This allows for the use of managed infrastructure services while maintaining logical isolation.

• Air-Gapped On-Premise: Deploying Hopsule in environments with no outbound internet access. This is the most secure configuration, often used by defense, government, or high-security research organizations.

System Requirements

To ensure the optimal performance of the Knowledge Graph and the Hopper advisory assistant, your infrastructure must meet the following minimum specifications. These requirements scale based on the number of active users and the depth of the decision history preserved within the system.

Important: The Knowledge Graph (also known as the Brain) requires sufficient memory to perform real-time relationship mapping between decisions and memories. Insufficient RAM may lead to latency when visualizing complex decision trees in the Hopsule Dashboard.

Installation and Initial Setup

The installation of Hopsule Enterprise is a structured process that begins with environment preparation and ends with the activation of the Hopsule API. Because Hopsule is a decision-first system, the setup process itself is designed to be documented and preserved as an initial memory entry within your new instance.

1. Provision Infrastructure: Allocate the necessary compute, storage, and networking resources according to the system requirements.

2. Configure Environment Variables: Define the operational parameters, including encryption keys, service endpoints, and authentication providers.

3. Initialize Data Volumes: Set up persistent storage for the append-only memory logs and the decision version history.

4. Deploy Container Suite: Pull the official Hopsule Enterprise images from the private registry and initiate the orchestration sequence.

5. Verify Connectivity: Ensure that the Hopsule CLI and Hopsule for VS Code can successfully communicate with the self-hosted Hopsule API.

Tip: During the initial setup, we recommend creating a "System Bootstrap" Context Pack to record the reasoning behind your specific infrastructure choices. This ensures that future maintainers understand the context of the deployment.

Configuration and Environment Management

Configuration of the self-hosted instance is managed through a central environment file. This file controls how the Hopsule Dashboard interacts with the underlying memory layer and how Hopper accesses the Knowledge Graph for RAG-powered suggestions. It is critical that these settings are managed securely, as they define the authority and governance boundaries of the system.

Key configuration areas include:

• Authentication: Integration with OIDC or SAML providers to ensure that only authorized personnel can accept or deprecate decisions.

• Endpoint Mapping: Defining the internal URLs for the Hopsule API so that the Hopsule CLI and IDE extensions can route traffic correctly. Encryption Keys: Managing the master keys used for AES-256 encryption of data at rest. In a self-hosted environment, the customer retains sole possession of these keys.

Note: All Hopsule deployments, including self-hosted, utilize TLS 1.3 for data in transit. Even within a private network, internal communication between services is encrypted by default to maintain a zero-trust architecture.

Customer Responsibilities

While Hopsule provides the software and the framework for decision enforcement, the operational integrity of a self-hosted instance is the sole responsibility of the customer. Hopsule does not have access to your self-hosted environment and cannot perform administrative tasks on your behalf. This separation is fundamental to the data sovereignty guarantee of the Enterprise plan.

Data Security and Encryption

The customer is responsible for managing the security of the underlying infrastructure, including network firewalls, intrusion detection systems, and physical security. While Hopsule provides the mechanisms for AES-256 encryption, the customer must manage the lifecycle of the encryption keys. If keys are lost, Hopsule cannot recover the encrypted memories or decisions, as we do not maintain backdoors or escrow services for self-hosted installations.

Backups and Disaster Recovery

Because Hopsule serves as the "memory" of your organization, the loss of data can be catastrophic for engineering governance. Customers must implement a robust backup strategy that includes regular snapshots of the persistent storage volumes. We recommend a multi-region backup approach to ensure that your Context Packs and Capsules remain available even in the event of a regional infrastructure failure. Disaster recovery drills should be performed at least quarterly to verify the integrity of the backup data.

Infrastructure Maintenance and Scaling

The customer must monitor the resource utilization of the Hopsule services and scale the infrastructure as the organization grows. This includes applying security patches to the underlying operating system and container runtime. Hopsule provides updates for the application layer, but the health of the host environment remains a customer concern. Failure to maintain the host environment may lead to performance degradation in the Hopsule Dashboard or connectivity issues with the Hopsule CLI.

Uptime and Availability

The Standard SLA provided for Hopsule Cloud does NOT apply to self-hosted deployments. The customer is responsible for defining and maintaining their own availability targets. Hopsule provides the software to enable high-availability configurations (such as multi-node clusters), but the implementation and monitoring of these configurations are managed by the customer's DevOps or Site Reliability Engineering (SRE) teams.

Updates and Lifecycle Management

Hopsule regularly releases updates that include new features for the Knowledge Graph, improvements to the Hopper AI assistant, and security enhancements. In a self-hosted environment, the customer controls the cadence of these updates. This is particularly important for organizations that require a "frozen" environment during critical product launches or audit periods.

The update process typically involves:

1. Reviewing the release notes for changes to the Hopsule API or Context Pack schemas.

2. Pulling the latest container images from the Hopsule Enterprise registry.

3. Performing a staged rollout in a pre-production environment to verify compatibility with internal tools.

4. Updating the production instance and verifying the persistence of all existing Decisions and Memories.

Important: While Hopsule maintains backward compatibility for Context Packs, we strongly recommend keeping your self-hosted instance within two major versions of the current release to ensure access to the latest security patches and feature sets.

Security and Sovereignty Baseline

Security is not a premium feature in Hopsule; it is a baseline guarantee. Even in the self-hosted model, the principles of end-to-end encryption and role-based access control (RBAC) are strictly enforced. The Hopsule Dashboard provides an audit trail that records every change to the decision lifecycle—from Draft to Accepted to Deprecated. This audit trail is stored within your own database, providing a permanent record for compliance reporting and SOC 2 readiness.

For organizations using Hopsule for VS Code, the self-hosted model ensures that no source code or decision context is ever transmitted to Hopsule-managed servers. All contradiction detection and enforcement warnings are processed locally or against your self-hosted Hopsule API endpoint. This "local-first" approach to enforcement ensures that developers can work with confidence, knowing their context remains private.

Migration Between Cloud and Self-Hosted

Hopsule supports the migration of organizational memory between our cloud-hosted service and self-hosted environments. This flexibility allows teams to start on the cloud for rapid onboarding and transition to a self-hosted model as their security requirements evolve. Migration is facilitated through the export and import of Context Packs.

• Cloud to Self-Hosted: Export your active Capsules and Knowledge Graph data from the Hopsule Cloud Dashboard and import them into your initialized self-hosted instance.

• Self-Hosted to Cloud: Should your organizational strategy change, data can be exported from your private instance and securely uploaded to the Hopsule Cloud environment, provided that all encryption protocols are aligned.

During migration, the full version history of every decision is preserved, ensuring that the "why" behind your engineering choices—the Memories—remains intact. Traceability is never sacrificed for portability.

Enterprise Support and Channels

Self-hosted Enterprise customers receive priority support to assist with the complexities of managing a private decision layer. While Hopsule staff cannot access your environment directly, we provide expert guidance on configuration, scaling, and troubleshooting. Support is focused on the Hopsule software layer and its interaction with your infrastructure.

Available support channels include:

• Dedicated Technical Account Manager: A single point of contact for architectural reviews and deployment planning.

• Priority Email Support: Accelerated response times for technical inquiries regarding the Hopsule API or Hopsule CLI.

• Private Documentation Portal: Access to advanced deployment guides, reference architectures, and security hardening checklists.

• Emergency Hotlines: For critical issues affecting the availability of the decision enforcement engine.

For more information on the Hopsule Enterprise plan and to request access to the self-hosted binaries, please contact our sales and engineering team through the Hopsule Dashboard or your account representative.

Conclusion: The Value of Absolute Memory

Deploying Hopsule as a self-hosted system is a commitment to the long-term preservation of organizational judgment. It acknowledges that decisions are the most valuable assets an engineering team possesses and that the context surrounding those decisions deserves the highest level of protection. By managing your own Hopsule instance, you ensure that your team's memory is not just stored, but is an enforceable, sovereign, and permanent part of your engineering culture.

As your organization grows, the Knowledge Graph will expand, Hopper will provide more nuanced advice, and your Context Packs will become the foundation upon which new projects are built. Self-hosting ensures that this foundation is built on your own ground, under your own authority, forever.