# Welcome to HashSphere Documentation

HashSphere is an enterprise-grade, private, permissioned network based on Hedera technology. It is delivered as a managed service on AWS or GCP.

Use the sections below to get oriented quickly.

<table data-card-size="large" data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-target data-type="content-ref">Link</th></tr></thead><tbody><tr><td align="center"><strong>HashSphere Explained</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/8vFrrzg7v03UtSJLQ7qN">/spaces/1lwtTuSxq9S9wuqIw74y/pages/8vFrrzg7v03UtSJLQ7qN</a></td></tr><tr><td align="center"><strong>FAQs</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/9JrHgT8zstLtiJfXszvK">/spaces/1lwtTuSxq9S9wuqIw74y/pages/9JrHgT8zstLtiJfXszvK</a></td></tr><tr><td align="center"><strong>Managed Service</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/xNixkvDFpNfA0M6oOipb">/spaces/1lwtTuSxq9S9wuqIw74y/pages/xNixkvDFpNfA0M6oOipb</a></td></tr><tr><td align="center"><strong>Development</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/Vbqge3sXJuRW0l4FcUNh">/spaces/1lwtTuSxq9S9wuqIw74y/pages/Vbqge3sXJuRW0l4FcUNh</a></td></tr><tr><td align="center"><strong>Operations</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/tL12rfS9fQIne2yPXnl5">/spaces/1lwtTuSxq9S9wuqIw74y/pages/tL12rfS9fQIne2yPXnl5</a></td></tr><tr><td align="center"><strong>Support</strong></td><td><a href="/spaces/1lwtTuSxq9S9wuqIw74y/pages/JQ0MQNeQAQA3W0ifREdP">/spaces/1lwtTuSxq9S9wuqIw74y/pages/JQ0MQNeQAQA3W0ifREdP</a></td></tr></tbody></table>


# Introduction to HashSpheres

HashSpheres are enterprise-grade, private, permissioned instances of Hedera networks. They are designed for organizations that require the advanced capabilities of Hedera's technology but are unable to use the public mainnet due to specific regulatory, operational, or governance constraints.

### What is a HashSphere?

HashSpheres provide a dedicated ledger environment, enabling organizations to meet requirements such as:

* **Data privacy**: restrict network access and visibility.
* **Permissioned access**: control who can submit transactions and run nodes.
* **Custom governance**: align policies, operations, and approvals to your model.
* **Data residency**: keep infrastructure in a required region.

### Technology foundation

A HashSphere is a private instance of the same open-source Hiero codebase that powers the Hedera public mainnet. [This code](https://github.com/hiero-ledger), managed by the Linux Foundation's Decentralized Trust (LFDT), ensures that HashSpheres benefit from the same core features and developer tools available on the public network.

Applications built on a HashSphere can leverage Hedera's full suite of network services:

* [Hedera Smart Contract Service (HSCS)](https://docs.hedera.com/hedera/core-concepts/smart-contracts): Fully EVM-compatible layer with bridging capability between EVM smart contracts and Hedera's native services.
* [Hedera Token Service (HTS)](https://docs.hedera.com/hedera/core-concepts/tokens): Offers fast, affordable token creation and transfers without complex smart contracts.
* [Hedera Account Service (HAS)](https://docs.hedera.com/hedera/core-concepts/accounts): Transfer private network tokens between accounts.
* [Hedera Consensus Service (HCS)](https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms): High-throughput event ordering and messaging to support auditable workflows.
* [Hedera File Service (HFS)](https://docs.hedera.com/hedera/sdks-and-apis/sdks/file-service): Store small files on the ledger (\~1024 KB).

{% hint style="info" %}
For SDK usage and protocol behavior, use the [Hedera documentation](https://docs.hedera.com/hedera/sdks-and-apis) as the source of truth.
{% endhint %}

### HashSphere Managed Service

HashSpheres are offered as a fully managed service, operated by the operations team at Hashgraph. Customers receive a private Hedera network configured to their unique requirements and backed by enterprise-grade support. HashSpheres are deployed on either Amazon Web Services (AWS) or Google Cloud Platform (GCP) within a segregated and secure cloud account. A typical deployment includes:

* Four [Consensus nodes](https://github.com/hiero-ledger/hiero-consensus-node) across multiple AZs.
* One [Mirror node](https://docs.hedera.com/hedera/core-concepts/mirror-nodes) for optimized read access and history.
* One [JSON-RPC relay](https://docs.hedera.com/hedera/core-concepts/smart-contracts/json-rpc-relay) that enables submission of EVM transactions to the network.
* A private [network explorer](https://hashscan.io/) for viewing accounts, transactions, and on-ledger activity.
* A [HashSphere Console](/operations/hashsphere-console) monitoring tool for observing the overall health and performance of the network and its components.

Depending on your requirements, it may also include:

* Upgrade and maintenance processes.
* Backup and restore capabilities.
* Monitoring integrations.
* Enhanced support workflows.

### Learn more

Contact the HashSphere Business Development team via the [contact page](https://www.hashgraph.com/contact/) on the Hashgraph website.


# HashSphere FAQs

Common questions about HashSphere Managed Service. This covers scope, operations, and shared ownership.

Go deeper here:

* [Introduction to HashSpheres](/hashsphere-explained/introduction-to-hashspheres)
* [Architecture Overview](/managed-service/architecture-overview)
* [Support Overview](/support/support-overview)

### Service basics

<details>

<summary><strong>What is HashSphere Managed Service?</strong></summary>

HashSphere Managed Service is a fully-managed, enterprise-grade private ledger offering operated by the HashSphere engineering team on AWS or GCP. It allows organizations to run a permissioned network aligned with Hedera technology without needing to manage nodes, upgrades, or infrastructure operations themselves.

HashSphere Managed Service provides:

* Managed network operations with defined SLAs
* Proactive monitoring and maintenance
* Backup and recovery
* Structured support and escalation policies
* Clear operational boundaries between HashSphere and the customer

</details>

<details>

<summary><strong>Who is HashSphere Managed Service designed for?</strong></summary>

HashSphere Managed Service is designed for organizations that need:

* Production-grade reliability and uptime guarantees
* Predictable operations rather than ad-hoc support
* Enterprise-grade security and compliance alignment

This includes regulated industries, financial services, payments, supply chain, and enterprise application teams, to name a few.

</details>

<details>

<summary><strong>What does “fully managed” mean?</strong></summary>

Fully managed means:

* HashSphere engineers deploy, operate, monitor, and maintain the HashSphere network
* The HashSphere team handles node health, upgrades, backups, and incident response
* Customers do not require blockchain infrastructure expertise

Customers can instead focus on building applications and integrations, not running nodes.

</details>

<details>

<summary><strong>What cloud providers are supported?</strong></summary>

HashSphere runs on AWS or GCP. Deployments are single-region and span multiple Availability Zones by default.

</details>

### Operations

<details>

<summary><strong>What uptime and reliability guarantees are provided?</strong></summary>

HashSphere Managed Service includes the following:

* Published uptime SLAs (≥ 99.9%).
* Defined maintenance windows.
* Clear definitions of what services are included in uptime calculations.

Planned maintenance is communicated in advance and accounted for as part of the SLA agreements.

</details>

<details>

<summary><strong>How are incidents handled?</strong></summary>

Incidents are managed through our support portal, with tickets serving as the primary source of truth. HashSphere Managed Service employs a tiered support and escalation model:

* **Ticket Submission:** Customers submit tickets via Zendesk.
* **Guaranteed Response Times:** Response times are guaranteed based on the customer’s support contract.
* **Clear Escalation Paths:** Incidents can be escalated to Solution Architects, engineers, or product teams as needed.
* **Structured Communication:** We ensure systematic communication throughout the incident lifecycle.

Start here:

* [Support Overview](/support/support-overview)
* [Raising Support Tickets](/support/raising-support-tickets)

</details>

<details>

<summary><strong>What monitoring and visibility do customers get?</strong></summary>

Every network includes the [HashSphere Console](/operations/hashsphere-console). It integrates with your SSO provider.

You can view node health, endpoint availability, and network status. This helps you validate issues before opening a ticket.

</details>

<details>

<summary><strong>How does backup and recovery work?</strong></summary>

HashSphere provides automated backups and restore capabilities. Backup scope and recovery objectives depend on your service contract.

See [Network Backup and Restore](/operations/network-backup-and-restore).

</details>

### Security & access

<details>

<summary><strong>What is the shared responsibility model?</strong></summary>

HashSphere operates the managed platform. This includes nodes, upgrades, monitoring, backups, and platform incidents.

Customers operate the customer environment and application. This includes app deployment, access policies, and signing keys.

Use [Architecture Overview](/managed-service/architecture-overview) for boundary details.

</details>

<details>

<summary><strong>Who owns keys, certificates, and infrastructure?</strong></summary>

Ownership depends on how the key is used. HashSphere runs the infrastructure. Customers own transaction signing keys.

<table><thead><tr><th width="196.251953125">Item</th><th width="343.2294921875">Examples</th><th>Owned and operated by</th></tr></thead><tbody><tr><td><strong>Consensus node keys</strong></td><td>Node identity keys, gossip/TLS material</td><td><strong>Hashgraph</strong></td></tr><tr><td><strong>Mirror / RPC / explorer service certificates</strong></td><td>Ingress TLS certs, internal mTLS certs</td><td><strong>Hashgraph</strong></td></tr><tr><td><strong>Infrastructure access credentials</strong></td><td>Cloud account/project, Kubernetes control plane, CI for platform components</td><td><strong>Hashgraph</strong></td></tr><tr><td><strong>Platform/admin secrets</strong></td><td>Monitoring credentials, service-to-service secrets, platform admin accounts</td><td><strong>Hashgraph</strong></td></tr><tr><td><strong>Customer ledger account keys (transaction signing)</strong></td><td>Operator keys used by apps, treasury keys for customer-issued tokens, contract admin keys</td><td><strong>Customer</strong></td></tr><tr><td><strong>Customer auth/identity configuration</strong></td><td>SSO/IdP config, user access policies in the customer environment</td><td><strong>Customer</strong></td></tr></tbody></table>

HashSphere can bootstrap initial accounts during onboarding. Customer-owned keys are transferred using secure mechanisms.

</details>

### Integrations & development

<details>

<summary><strong>Can customers integrate wallets, custody providers, or partners?</strong></summary>

Yes. HashSphere supports integrations with wallets, custody, and third-party tooling.

Customers provision partner access. HashSphere provides required network identifiers and endpoints.

</details>

<details>

<summary><strong>Can customers deploy applications automatically?</strong></summary>

Yes. Use standard enterprise CI/CD for customer applications.

HashSphere provides stable environment details for automation. Your team owns pipelines and releases.

See [HashSphere Application Deployment](/development/application-deployment).

</details>

### Data & privacy

<details>

<summary><strong>Is customer data private?</strong></summary>

HashSphere is permissioned. Access is restricted to approved participants.

Connectivity is typically private. Examples include AWS PrivateLink and GCP Private Service Connect.

Data is encrypted in transit and at rest. Your application still controls what you publish on-ledger.

HashSphere APIs do not enforce your app auth model by default. Use a customer-managed proxy or gateway for fine-grained control.

Advanced privacy features may ship in future releases. Treat them as roadmap until contracted.

</details>


# Architecture Overview

This section describes the base components deployed as part of a HashSphere managed service engagement and how a customer connects into the HashSphere.

This document outlines the core components of HashSphere Managed Service. It also covers the standard connectivity model for customer applications.

A typical solution has two distinct parts:

* **The HashSphere:** A private, managed Hedera ledger.
* **The Customer Application:** The business system that interacts with the HashSphere.

A typical deployment is illustrated below.

<figure><img src="/files/r00mAy0nwFBEGYKU4Vhk" alt=""><figcaption></figcaption></figure>

***

### HashSphere (managed platform)

The HashSphere is a private Hedera ledger. It runs on the same Hiero technology stack as Hedera mainnet.

HashSphere is deployed and operated by the HashSphere SRE team. The team configures the environment to match each customer’s requirements.

#### Key features

* **Managed Service:** The HashSphere is managed exclusively by the HashSphere team. Customers do not have direct access to the underlying infrastructure's configuration or management.
* **Customer Isolation:** Each HashSphere is deployed within a dedicated cloud account (AWS) or project (GCP). This isolates customers from one another, preventing resource competition and ensuring security.
* **High Availability:** The HashSphere's compute components are managed within a Kubernetes cluster and are replicated across multiple Availability Zones (AZs) to ensure resilience against data center outages.
* **Managed Storage:** Storage is provided by highly reliable managed services from the cloud provider, such as AWS S3/RDS or GCP Cloud Storage/Cloud SQL.
* **Load Balancing:** A load balancer distributes API requests for the Mirror Node, Admin Dashboard, and HashScan across the replicated instances to ensure optimal performance and availability.

The following components are deployed within the HashSphere.

#### Consensus nodes

These nodes work together to achieve consensus on the ledger's state. A standard HashSphere deployment includes four consensus nodes, which allows the network to maintain consensus even if one node goes offline (tolerating f=1 failures in a network of 3f+1 nodes). For enhanced high-availability, more nodes can be configured. To protect against regional outages, nodes are distributed across the available AZs. For example, in a region with three AZs, the nodes are deployed in a 2-1-1 configuration.

For more information on consensus nodes, please refer to the [Hedera documentation](https://github.com/hiero-ledger/hiero-consensus-node/tree/main/hedera-node/docs).

#### Mirror nodes

Mirror nodes provide an optimized, read-only view of the ledger. They store the complete and finalized state of the ledger, as well as all historical transactions. These nodes are replicated across Availability Zones for high availability. Each mirror node is backed by a managed Postgres database. Mirror nodes expose a REST API for querying ledger state and history, a gRPC endpoint for subscribing to Hedera Consensus Service (HCS) events, and a JSON-RPC relay for interacting with Hedera's EVM capabilities.

For more information on mirror nodes, please refer to the [Hedera documentation](https://docs.hedera.com/hedera/core-concepts/mirror-nodes).

#### HashSphere Console

The HashSphere Console provides visibility into the health and performance of the managed platform. It is intended for customer DevOps and support teams.

For setup and usage, see [HashSphere Console](/operations/hashsphere-console).

#### Network explorer

This service provides a private block explorer for the HashSphere ledger, offering the same functionality as the public HashScan for the Hedera mainnet and testnet.

***

### Customer application

The customer is responsible for managing their own cloud account/project and the business application that runs within their Virtual Private Cloud (VPC). The HashSphere team facilitates secure interaction by making the HashSphere APIs available within the customer's VPC.

#### Connectivity and responsibilities

* **Secure Connectivity:** The connection between the customer's application and the HashSphere is established using private, secure endpoints, such as AWS PrivateLink or GCP Private Service Connect. The HashSphere team ensures that only the necessary IP addresses and ports for API access are opened, with no other access permitted.
* **Boundary of Responsibility:** The API endpoints represent the clear boundary of responsibilities. The HashSphere team is responsible for the operational integrity and availability of the HashSphere and its APIs. The customer team is responsible for the development, deployment, and maintenance of their business application that consumes these APIs.
* **Access Management:** The HashSphere APIs do not have built-in access management. Customers are encouraged to implement a proxy or API gateway in front of the endpoints to enforce their own access control policies.
* **Key Management:** The customer is solely responsible for managing the private key material required to control their ledger accounts. This can be achieved through a third-party custody provider or by integrating a Hardware Security Module (HSM) into their application. The HashSphere team will securely transfer the necessary network account keys during the initial setup.
* **Ledger Interaction:** While the HashSphere team maintains the private ledger infrastructure, the customer is responsible for all on-ledger activities, such as deploying smart contracts, managing digital assets, and submitting transactions.
* **Multi-VPC Connectivity:** For use cases requiring multiple, distributed application instances, the HashSphere team can make the ledger endpoints available in multiple customer VPCs.

***

### Supported cloud platforms

HashSphere can be deployed on both **Amazon Web Services (AWS)** and **Google Cloud Platform (GCP)**. The customer's business application must be hosted on the same cloud platform as their HashSphere instance.

{% hint style="info" %}
If you require a different cloud platform, contact the team via the [Hashgraph contact page](https://www.hashgraph.com/contact/).
{% endhint %}


# Provisioning Overview

This checklist outlines the minimum information required to provision a HashSphere. Providing this information ensures your HashSphere is deployed in alignment with your organization's needs.

Provisioning a HashSphere is a shared process between your team and the HashSphere team. This page lists the minimum inputs needed to deploy an environment.

Before deployment begins, we work with you to understand a small set of foundational requirements. These inputs are critical because they determine:

* Infrastructure placement and compliance alignment
* Data residency and regulatory posture
* Access control and identity integration
* Core network identifiers used across integrations

These inputs allow the HashSphere team to design and deploy your environment in alignment with your organization’s infrastructure, security, and compliance requirements.

The sections below outline the primary topics discussed during provisioning.

### Cloud provider and region selection

HashSpheres can be deployed on AWS or GCP.

HashSphere endpoints are exposed using:

* Virtual Private Cloud Endpoints (AWS)
* Private Service Connect (GCP)

For this reason, the cloud provider selected for the HashSphere must align with the cloud provider hosting the services that will interact with it. This ensures secure, private connectivity without requiring public internet exposure.

HashSpheres can be deployed to any supported region. Region selection is typically influenced by your existing infrastructure footprint, security policies, latency considerations, and data residency requirements.

The HashSphere team will work with you to determine the optimal deployment pattern based on your technical and regulatory requirements.

### Data residency

Prior to provisioning, we clarify any data residency constraints that apply to your organization. These may include requirements for data to live within a single region, jurisdictional restrictions, or your internal governance policies.

Understanding these requirements ensures HashSphere components are deployed appropriately. It also ensures [backup storage](/operations/network-backup-and-restore) aligns with your constraints.

### Identity and access integration

The HashSphere Console integrates with your enterprise identity provider to enable secure, role-based access. Prior to HashSphere provisioning, we confirm your identity provider (e.g., Okta, Ping), SSO integration requirements, and access model.

This allows your teams to monitor the network using your existing enterprise authentication framework without introducing separate credential systems.

### Currency identifiers

Each HashSphere network requires core identifiers that are referenced by wallets, custody providers, explorers, SDKs, and partner integrations. We will confirm the following:

* HashSphere currency name
* HashSphere ticker symbol

Defining these identifiers upfront ensures consistent ecosystem representation and prevents downstream integration issues once your applications and partners are connected.

### Admin key management

Each HashSphere includes an administrative key used for foundational network operations such as:

* Creating initial accounts
* Funding accounts for development
* Supporting early integration and onboarding

Prior to provisioning, we identify the designated recipient for this key and a secure method of key delivery. Designating a responsible recipient ensures secure handling and minimizes operational risk.


# Application Development on HashSphere

This page will highlight the main differences developers should consider when developing HashSphere applications vs Hedera mainnet applications.

This section highlights the key similarities and differences developers should consider when building applications for a private HashSphere environment versus the public Hedera mainnet.

While HashSpheres run the same core technology stack as the Hedera mainnet and testnet, the private, permissioned nature of a HashSphere introduces unique environmental and operational considerations. However, the fundamental development patterns and core APIs remain consistent.

***

### Core API Consistency

Your core developer experience remains largely unchanged. The primary Hedera APIs function the same way on HashSphere as they do on the public networks. You can and should continue to use the main [Hedera documentation](https://docs.hedera.com/) as your primary reference.

Key services that remain consistent include:

* **HAPI**: The core ledger APIs for the Hedera Consensus, Token, File, and Crypto Services.
* **Hedera Smart Contract Service (HSCS)**: The APIs for deploying and interacting with EVM-compatible smart contracts.
* **Mirror Node**: The REST APIs for querying historical data and the gRPC subscriptions for receiving real-time event streams.

***

### Guides

* [**Development Environments**](/development/application-development-on-hashsphere/development-environment)
  * Choose a development environment for fast iteration and testing.
* [**SDK Client Configuration**](/development/application-development-on-hashsphere/sdk-client-configuration)
  * Configure an SDK client to connect to a private HashSphere network.
* [**Application Design Considerations**](/development/application-development-on-hashsphere/application-design-considerations)
  * Understand the primary design differences between public and private networks.


# Development Environment

Before you can begin building applications on a private Hedera network, you need to choose a development environment. This page outlines the available options for fast iteration and testing.

***

### Prerequisites

Before choosing a development environment, you should have a basic understanding of the following:

* The Hedera Network ([testnet](https://docs.hedera.com/hedera/networks/testnet), [previewnet](https://docs.hedera.com/hedera/networks/testnet), and [mainnet](https://docs.hedera.com/hedera/networks/mainnet))
* Hedera accounts and clients
* Transaction and query basics

If you are new to Hedera, we recommend starting with the [Hedera Developer Portal](https://portal.hedera.com) to get up to speed.

***

### Public Networks

For many public applications, the Hedera [**testnet**](https://docs.hedera.com/hedera/networks/testnet) or [**previewnet**](https://docs.hedera.com/hedera/networks/previewnet) are suitable for development and testing. These networks are free to use and provide a sandbox environment that closely mirrors the mainnet.

* **Testnet**: Runs the same code as the Hedera mainnet, providing a stable, pre-production environment for testing applications before deploying them to the mainnet.
* **Previewnet**: Offers early access to upcoming features and code that is under development by the Hedera team. The previewnet is updated frequently, and SDK support for new features is not guaranteed.

If the public networks are not suitable for your needs—for example, if you require a completely isolated environment or need to test specific network configurations—you have two private network options.

***

### Private Network Options

#### 1. Solo

[**Solo**](https://docs.hedera.com/hedera/networks/localnet) is a command-line interface (CLI) for deploying and managing standalone, single-node test networks. You can run a Solo network on a laptop or in a dedicated development environment.

To get started with Solo, see the [getting started guide](https://github.com/hashgraph/solo) in the official repository.

#### 2. Test HashSphere

For enterprise teams, a dedicated **Test HashSphere** provides a private, managed environment for development and testing. Customer operations teams typically manage access to this environment.

**Key Features**

* **Private Network**: A completely isolated network environment, giving you full control over network configuration, node management, and data privacy.
* **Predictable Performance**: Consistent and predictable performance, as you are not competing for resources with other users on a public network.
* **Custom Configurations**: The ability to test specific network configurations, such as custom transaction throttles or different node software versions.

**Onboarding**

To get started with a Test HashSphere, you will need to contact the Hashgraph team to begin the onboarding process. The team will provide you with the necessary node address book and required identifiers to configure your SDK client.

{% hint style="info" %}
To request a Test HashSphere or to discuss your specific requirements, please contact the team via the [Hashgraph contact page](https://www.hashgraph.com/contact/).
{% endhint %}


# SDK Client Configuration

To interact with a HashSphere network, you use a Hiero SDK client. The Hiero SDKs provide a common foundation for interacting with any Hedera-powered network, including the public Hedera mainnet, its testnets, and private networks like HashSphere. While the public networks have helper functions for easy connection (`Client.forMainnet()`, `Client.forTestnet()`), configuring a client for a private network requires explicitly providing the network's node addresses.

#### Prerequisites

{% hint style="info" %}
Before you begin, ensure you have the following:

* The appropriate Hiero SDK installed for your preferred language (Java, JavaScript, Go, or Rust).
* Your network address book and account credentials, provided by the HashSphere team during onboarding.
  {% endhint %}

***

### 1. Configure Your Network Connection

For local networks and private HashSpheres, you configure the SDK client by passing it the node address book. The address book is a map containing the IP addresses or domain names of the network nodes and their corresponding node account IDs.

The HashSphere team provides you with the node address book and required identifiers during the onboarding process.

{% tabs %}
{% tab title="JavaScript" %}

```javascript
import { Client, AccountId } from "@hashgraph/sdk";

const nodes = {
  "xxx.xxx.xxx.xxx:50211": new AccountId(3),
  "yyy.yyy.yyy.yyy:50211": new AccountId(4),
};

const client = Client.forNetwork(nodes);
```

{% endtab %}

{% tab title="Java" %}

```java
import com.hedera.hashgraph.sdk.Client;
import com.hedera.hashgraph.sdk.AccountId;
import java.util.Map;
import java.util.HashMap;

Map<String, AccountId> nodes = new HashMap<>();
nodes.put("xxx.xxx.xxx.xxx:50211", AccountId.fromString("0.0.3"));
nodes.put("yyy.yyy.yyy.yyy:50211", AccountId.fromString("0.0.4"));

Client client = Client.forNetwork(nodes);
```

{% endtab %}

{% tab title="Go" %}

```go
import (
    "github.com/hashgraph/hedera-sdk-go/v2"
)

nodes := map[string]hedera.AccountID{
    "xxx.xxx.xxx.xxx:50211": hedera.AccountID{Account: 3},
    "yyy.yyy.yyy.yyy:50211": hedera.AccountID{Account: 4},
}

client := hedera.ClientForNetwork(nodes)
```

{% endtab %}

{% tab title="Rust" %}

```rust
use hedera::{
    Client,
    AccountId,
};
use std::collections::HashMap;

let nodes: HashMap<String, AccountId> = [
    ("xxx.xxx.xxx.xxx:50211".to_owned(), AccountId::new(0, 0, 3)),
    ("yyy.yyy.yyy.yyy:50211".to_owned(), AccountId::new(0, 0, 4)),
].into();

let client = Client::for_network(nodes)?;
```

{% endtab %}
{% endtabs %}

***

### 2. Define the Operator

The operator is the account that pays for transactions and queries submitted through the client. You must configure the client with an operator account ID and its corresponding private key.

For improved security and convenience, we recommend using a `.env` file to store your credentials rather than hardcoding them in your application. Make sure your `.env` file is included in your `.gitignore`.

#### Using a `.env` file

Create a `.env` file in the root of your project:

```
OPERATOR_ID=0.0.xxxx
OPERATOR_KEY=302e020100300506032b657004220420...
```

Then, load these variables into your application and set the operator on the client.

{% tabs %}
{% tab title="JavaScript" %}

```javascript
import "dotenv/config";

const operatorId = AccountId.fromString(process.env.OPERATOR_ID);
const operatorKey = PrivateKey.fromString(process.env.OPERATOR_KEY);

client.setOperator(operatorId, operatorKey);
```

{% endtab %}

{% tab title="Java" %}

```java
import io.github.cdimascio.dotenv.Dotenv;

AccountId operatorId = AccountId.fromString(Dotenv.load().get("OPERATOR_ID"));
PrivateKey operatorKey = PrivateKey.fromString(Dotenv.load().get("OPERATOR_KEY"));

client.setOperator(operatorId, operatorKey);
```

{% endtab %}

{% tab title="Go" %}

```go
import (
    "os"
    "github.com/joho/godotenv"
)

err := godotenv.Load()
// ... error handling

operatorID, err := hedera.AccountIDFromString(os.Getenv("OPERATOR_ID"))
// ... error handling
operatorKey, err := hedera.PrivateKeyFromString(os.Getenv("OPERATOR_KEY"))
// ... error handling

client.SetOperator(operatorID, operatorKey)
```

{% endtab %}

{% tab title="Rust" %}

```rust
use std::env;

let operator_id: AccountId = env::var("OPERATOR_ID")?.parse()?;
let operator_key: PrivateKey = env::var("OPERATOR_KEY")?.parse()?;

client.set_operator(operator_id, operator_key);
```

{% endtab %}
{% endtabs %}

***

### Client Configuration API Reference

The following table lists the primary methods for configuring the SDK client for a HashSphere network.

| Method                                          | Description                                                                  |
| ----------------------------------------------- | ---------------------------------------------------------------------------- |
| `Client.forNetwork(<network>)`                  | Constructs a client for a custom network using a provided address book.      |
| `client.setOperator(<accountId>, <privateKey>)` | Sets the account that will pay for transactions and queries.                 |
| `client.setMirrorNetwork(<network>)`            | Defines a specific mirror node network for the client to use.                |
| `client.getMirrorNetwork()`                     | Returns the configured mirror node network.                                  |
| `client.setDefaultMaxTransactionFee(<fee>)`     | Sets the default maximum fee the client is willing to pay for a transaction. |
| `client.setDefaultMaxQueryPayment(<payment>)`   | Sets the default maximum payment the client is willing to pay for a query.   |

For a complete list of client configuration options, see [Building your Hedera client](https://docs.hedera.com/hedera/sdks-and-apis/sdks/client).


# Application Design Considerations

Application design for a private HashSphere differs from public network design in a few key areas. This page outlines the primary considerations to keep in mind when building applications for a private Hedera network.

***

### Public Mainnet vs. Private HashSphere

The following table compares the design considerations for applications built on the public Hedera [mainnet](https://docs.hedera.com/hedera/networks/mainnet) versus a private HashSphere.

| Consideration         | Public Mainnet                                                                                                                                                                                | Private HashSphere                                                                                                                                                          |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cost Model**        | Applications must optimize for [transaction fees](https://docs.hedera.com/hedera/networks/mainnet/fees), as every operation costs HBAR. The value of HBAR is determined by the public market. | HBAR does not carry real-world value. The supply and cost of operations are controlled by the network operator.                                                             |
| **Trust Environment** | The public mainnet is an open, permissionless environment where anyone can create an account and submit transactions.                                                                         | A permissioned environment with known actors operating under a defined governance model and legal contracts, with recourse for errors.                                      |
| **Data Visibility**   | All transaction data is publicly visible on the ledger. To maintain privacy, you should avoid storing sensitive information directly on-chain.                                                | Visibility is restricted to network participants. In-network privacy solutions, such as encrypting data before submission, can be employed to further enhance data privacy. |
| **Performance**       | Performance is subject to the public network's defined [transaction throttles](https://docs.hedera.com/hedera/networks/mainnet#main-network-throttles).                                       | Predictable performance can be tuned to meet specific application requirements. The network operator can configure custom throttles and resource limits.                    |

***

### Architectural Patterns and Review

When designing applications for a private HashSphere, it is important to consider the unique architectural patterns that a private, permissioned environment enables. These may include:

* **Identity and Access Management**: Integrating with enterprise identity systems (e.g., LDAP, OAuth) to manage user access and permissions.
* **Data Privacy and Confidentiality**: Implementing application-level encryption and access control to protect sensitive data.
* **Integration with Existing Systems**: Connecting the HashSphere network to existing enterprise systems, such as databases, APIs, and messaging queues.

{% hint style="info" %}
If you would like to review your application architecture or discuss best practices for building on a private HashSphere, please contact the team via the [Hashgraph contact page](https://www.hashgraph.com/contact/).
{% endhint %}


# Application Deployment

This page covers how the managed platform is deployed and how you deploy your applications. It also clarifies the boundary between HashSphere responsibilities and customer responsibilities.

### HashSphere platform deployment (managed)

Deployment and operation of HashSphere instances is performed by the HashSphere team. For the platform component breakdown, see [Architecture Overview](/managed-service/architecture-overview).

HashSphere endpoints are private. They are exposed into the customer VPC using:

* AWS VPC endpoints (PrivateLink patterns)
* GCP Private Service Connect

There is no public internet access to HashSphere endpoints.

This can be depicted as follows:

<figure><img src="/files/AISoRh8PkVqo9bMxQp5S" alt=""><figcaption></figcaption></figure>

HashSphere endpoints do not enforce application-level authorization by default. They assume any workload in the customer VPC can reach them.

If you need fine-grained control, place a customer-managed proxy or API gateway in front of the endpoints.

To maintain segregation of duties, customers do not have access to internal HashSphere platform operations. Customers use the [HashSphere Console](/operations/hashsphere-console) for platform health visibility.

During onboarding, the HashSphere team can bootstrap initial accounts. Control of customer-owned accounts is passed to the customer.

### Customer application deployment

Use a standard CI/CD pipeline for application deployment. Treat HashSphere like any other production dependency.

#### Off-ledger components

Deploy your off-ledger services in your own VPC. These services call HashSphere via the private endpoints.

Customer operations teams deploy and operate customer services. The HashSphere team does not deploy customer components.

#### On-ledger components

Customers deploy and manage on-ledger components, for example:

* Administration and user account set up and funding
* HTS Token definition and deployment
* HCS topic configuration
* Smart contract deployment and management
* HFS configuration

For account bootstrap guidance, see [Creating Initial Accounts](/development/creating-initial-accounts).


# Developer Resources

This page provides a list of useful resources for developing HashSphere applications.

HashSpheres run the same core stack as Hedera mainnet and testnet. Most Hedera developer resources apply directly to HashSphere.

### Core docs

<table data-card-size="large" data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="image">Cover image</th></tr></thead><tbody><tr><td align="center"><a href="https://docs.hedera.com/"><strong>Hedera Documentation</strong></a></td><td><a href="https://docs.hedera.com/">https://docs.hedera.com/</a></td><td data-object-fit="contain"><a href="/files/vAEUBe4laytIRjKWkZaj">/files/vAEUBe4laytIRjKWkZaj</a></td></tr><tr><td align="center"><a href="https://hedera.com/knowledge-center/"><strong>Hedera Knowledge Center</strong></a></td><td><a href="https://hedera.com/knowledge-center/">https://hedera.com/knowledge-center/</a></td><td data-object-fit="contain"><a href="/files/vAEUBe4laytIRjKWkZaj">/files/vAEUBe4laytIRjKWkZaj</a></td></tr></tbody></table>

### Source code and tooling

{% embed url="<https://github.com/hashgraph>" %}
[Hashgraph GitHub organization](https://github.com/hashgraph) (studios and supporting tooling)
{% endembed %}

{% embed url="<https://github.com/hiero-ledger>" fullWidth="false" %}
[Hiero Ledger GitHub organization](https://github.com/hiero-ledger) (core node + SDK repos)
{% endembed %}

{% embed url="<https://github.com/hiero-ledger/solo>" %}
[Solo CLI](https://github.com/hiero-ledger/solo) (standalone test networks)
{% endembed %}

### SDKs and examples

<table data-view="cards"><thead><tr><th align="center"></th><th align="center"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hashgraph/hedera-sdk-java" alt="Java SDK cover"><br><strong>Java SDK</strong></td><td align="center"><p><a href="https://github.com/hashgraph/hedera-sdk-java"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-java/tree/main/examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hashgraph/hedera-sdk-java">https://github.com/hashgraph/hedera-sdk-java</a></td></tr><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hashgraph/hedera-sdk-js" alt="JavaScript SDK cover"><br><strong>JavaScript SDK</strong></td><td align="center"><p><a href="https://github.com/hashgraph/hedera-sdk-js"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-js/tree/main/examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hashgraph/hedera-sdk-js">https://github.com/hashgraph/hedera-sdk-js</a></td></tr><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hashgraph/hedera-sdk-go" alt="Go SDK cover"><br><strong>Go SDK</strong></td><td align="center"><p><a href="https://github.com/hashgraph/hedera-sdk-go"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-go/tree/main/examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hashgraph/hedera-sdk-go">https://github.com/hashgraph/hedera-sdk-go</a></td></tr><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hashgraph/hedera-sdk-swift" alt="Swift SDK cover"><br><strong>Swift SDK</strong></td><td align="center"><p><a href="https://github.com/hashgraph/hedera-sdk-swift"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-swift/tree/main/Examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hashgraph/hedera-sdk-swift">https://github.com/hashgraph/hedera-sdk-swift</a></td></tr><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hiero-ledger/hiero-sdk-rust" alt="Rust SDK cover"><br><strong>Rust SDK</strong></td><td align="center"><p><a href="https://github.com/hiero-ledger/hiero-sdk-rust"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-rust/tree/main/examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hiero-ledger/hiero-sdk-rust">https://github.com/hiero-ledger/hiero-sdk-rust</a></td></tr><tr><td align="center"><img src="https://opengraph.githubassets.com/1/hiero-ledger/hiero-sdk-cpp" alt="C++ SDK cover"><br><strong>C++ SDK</strong></td><td align="center"><p><a href="https://github.com/hiero-ledger/hiero-sdk-cpp"><mark style="color:$primary;"><strong>GitHub</strong></mark></a></p><p><a href="https://github.com/hiero-ledger/hiero-sdk-cpp/tree/main/src/sdk/examples"><mark style="color:$primary;"><strong>Examples</strong></mark></a></p></td><td><a href="https://github.com/hiero-ledger/hiero-sdk-cpp">https://github.com/hiero-ledger/hiero-sdk-cpp</a></td></tr></tbody></table>

### Hedera Portal

The portal connects to testnet and previewnet. It does not connect to HashSpheres. It is still useful for learning SDKs and Solidity patterns.

{% embed url="<https://portal.hedera.com/register>" %}
<https://portal.hedera.com/register>
{% endembed %}

### Hedera Studios

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th align="center"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><img src="https://opengraph.githubassets.com/1/hashgraph/asset-tokenization-studio" alt="Asset Tokenization Studio cover"><br><strong>Asset Tokenization Studio (ATS)</strong></td><td>An open-source platform for tokenizing and managing real-world assets and digital securities.</td><td align="center"><a href="https://github.com/hashgraph/asset-tokenization-studio/"><strong>GitHub</strong></a> <strong>|</strong> <a href="https://docs.hedera.com/hedera/open-source-solutions/asset-tokenization-studio-ats"><strong>Docs</strong></a> <strong>|</strong> <a href="https://tokenization-studio.hedera.com/"><strong>Demo</strong></a></td><td><a href="https://docs.hedera.com/hedera/open-source-solutions/asset-tokenization-studio-ats">https://docs.hedera.com/hedera/open-source-solutions/asset-tokenization-studio-ats</a></td></tr><tr><td><img src="https://opengraph.githubassets.com/1/hashgraph/stablecoin-studio" alt="Stablecoin Studio cover"><br><strong>Stablecoin Studio</strong></td><td>An open-source solution that offers granular access control for issuing stablecoins on the Hedera network.</td><td align="center"><a href="https://github.com/hashgraph/stablecoin-studio/"><strong>GitHub</strong></a> <strong>|</strong> <a href="https://docs.stablecoin-studio.hedera.com/"><strong>Docs</strong></a> <strong>|</strong> <a href="https://stablecoin-studio.hedera.com/"><strong>Demo</strong></a></td><td><a href="https://docs.hedera.com/hedera/open-source-solutions/stablecoin-studio">https://docs.hedera.com/hedera/open-source-solutions/stablecoin-studio</a></td></tr><tr><td><img src="https://opengraph.githubassets.com/1/hashgraph/guardian" alt="Guardian cover"><br><strong>Sustainability Studio (Guardian)</strong></td><td>A platform that streamlines the creation, management, and verification of digital environmental assets.</td><td align="center"><a href="https://github.com/hashgraph/guardian"><strong>GitHub</strong></a> <strong>|</strong> <a href="https://guardian.hedera.com/"><strong>Docs</strong></a></td><td><a href="https://guardian.hedera.com/">https://guardian.hedera.com/</a></td></tr><tr><td><img src="https://opengraph.githubassets.com/1/hashgraph/hedera-agent-kit-js" alt="AI Studio cover"><br><strong>AI Studio</strong></td><td>A development tool for building and deploying AI applications on the Hedera network.</td><td align="center"><a href="https://github.com/hashgraph/hedera-agent-kit-js"><strong>GitHub (JS)</strong></a><strong>,</strong> <a href="https://github.com/hashgraph/hedera-agent-kit-py"><strong>(PY)</strong></a> <strong>|</strong> <a href="https://docs.hedera.com/hedera/open-source-solutions/ai-studio-on-hedera"><strong>Docs</strong></a></td><td><a href="https://docs.hedera.com/hedera/open-source-solutions/ai-studio-on-hedera">https://docs.hedera.com/hedera/open-source-solutions/ai-studio-on-hedera</a></td></tr></tbody></table>


# Creating Initial Accounts

This guide explains how to create your first accounts on your organization’s HashSphere instance.

This guide covers account bootstrap on a newly provisioned HashSphere. It assumes you already have network connectivity to your private endpoints.

### What you are given

Every HashSphere environment is provisioned with an **operator account**. The HashSphere team provides this during onboarding.

You will be provided with:

* Operator Account ID
* Operator Public Key
* Operator Private Key
* Network address book (node addresses and IDs)

Together, these allow you to initialize a Hiero SDK client and create additional accounts.

By the end of this guide, you will be able to:

1. Connect to your HashSphere using a Hiero SDK
2. Create and fund new HashSphere accounts
3. Retrieve new Account IDs and manage their key pairs
4. Extend this pattern for automated or large-scale account provisioning

### Using the Hiero JavaScript SDK

#### Prerequisites

Before you begin, ensure you have:

* [ ] Operator Account ID (provided during onboarding)
* [ ] Operator Private Key (provided during onboarding)
* [ ] Network address book (provided during onboarding)
* [ ] Network access to your HashSphere endpoints
* [ ] A Node.js project with the Hiero JavaScript SDK installed ([install guide](https://docs.hedera.com/hedera/getting-started-hedera-native-developers/create-an-account#install-the-sdk))

{% hint style="info" %}
The Operator Private Key is a sensitive credential.

* Do not store it in source control.
* Do not transmit it in plaintext.
* Use environment variables, secure parameter stores, wallet solutions, or KMS/HSM integration where available.
  {% endhint %}

#### Setting up the client

To create accounts, your client must connect directly to your private HashSphere network. Configure the SDK with the node address book and your operator credentials.

For reference on client configuration patterns, see:

* [Building your Hedera client](https://docs.hedera.com/hedera/sdks-and-apis/sdks/client)
* [SDK Client Configuration](/development/application-development-on-hashsphere/sdk-client-configuration)

#### Creating an account

To create a new account, use the `AccountCreateTransaction` API from the Hiero SDK.

A code example to create a new account using the `AccountCreateTransaction` can be found in the Hedera documentation [here](https://docs.hedera.com/hedera/getting-started-hedera-native-developers/create-an-account#step-3-create-your-first-account-on-hedera).

#### Verifying account creation

You can confirm that your new account was created successfully using one of the following methods.

#### Option 1: HashScan

The HashSphere team will provide an environment-specific explorer URL.

To verify:

1. Navigate to the HashSphere explorer link
2. Search for the newly created Account ID
3. Confirm the transaction and account details

Access may be restricted to approved network environments.

#### Option 2: Mirror Node Query

You may also verify the account using the Mirror Node REST API. Sample code and the endpoint to query can be found [here](https://docs.hedera.com/hedera/getting-started-hedera-native-developers/create-an-account#step-4-query-the-account-balance-using-mirror-node-api).

Query the mirror node for the newly created Account ID to confirm:

* Account existence
* Transaction history
* Current balance

### Next steps

You now have the ability to:

* Create accounts programmatically
* Fund accounts using the Operator account
* Capture Account IDs and key pairs
* Integrate account creation into automated workflows

This same pattern can be extended for:

* Bulk account provisioning
* User onboarding systems
* Enterprise identity mapping


# HashSphere Console

How to integrate and use the HashSphere Console

### Overview

The HashSphere Console provides visibility into platform health and throughput. It is designed for DevOps and technical support teams.

You can view:

* Node and service status
* Transaction volume by type
* Transactions per second (TPS)
* Time to consensus

### Console setup

The HashSphere team sets up the Console. You configure your corporate identity provider (IdP) to grant access.

Your IdP must support OIDC. If it does not, coordinate an alternative during onboarding.

1. Create a new group within your IdP that will contain all the users who should have access to the Console. You could also reuse an existing group if you already have one that’s suitable.
2. Update the configuration of your IdP with the redirect URLs provided for your environment.

```
OIDC_REDIRECT_URL=https://iob.hashsphere.info/login/oidc/callback/
OIDC_LOGOUT_CALLBACK_URL=https://iob.hashsphere.info/login#
# This URL must also be added to the IdP configuration under "Allowed Logout URLs".
REDIRECT_POST_LOGIN=https://iob.hashsphere.info/dashboard/
```

{% hint style="info" %}
Replace `iob.hashsphere.info` with your Console domain. The HashSphere team will confirm the correct values during onboarding.
{% endhint %}

3. Share the following values with the HashSphere team:

```
OIDC_CLIENT_ID
```

```
OIDC_CLIENT_SECRET
```

```
OIDC_ISSUER_URL
```

```
OIDC_AUDIENCE
```

```
OIDC_SCOPE
```

### Adding users

To grant access, add users to the IdP group created for Console access.

Users also need network access to the HashSphere endpoints. Without that, they will not reach the Console login screen.

### Console data: dashboard

<figure><img src="/files/qXTkmcQEHYTPbOa6CD0M" alt="" width="563"><figcaption></figcaption></figure>

The Dashboard is the primary landing screen for the Console and contains overview information about the health and utilization of the environment.

#### Network overview

<figure><img src="/files/CKO3wU3JjEQXr0GN3PXd" alt="" width="375"><figcaption></figcaption></figure>

This screen includes:

* Total number of entities created. Entity limits depend on node sizing.
* A breakdown of commonly used entity types via **View Details**.

<figure><img src="/files/1FDBzLmKaUsViNCakfPB" alt="" width="375"><figcaption></figcaption></figure>

* Total user accounts created.
* Active consensus nodes shown as `active/total`.
* Mirror service health status.

#### Transactions

<figure><img src="/files/XTYLTZeaa2jjmXibVSr2" alt="" width="563"><figcaption></figcaption></figure>

This view shows transaction volumes across a selected time window. It includes totals and a breakdown by transaction type.

#### Transactions per second

<figure><img src="/files/pCl5gbyTQsrwuChd6K3S" alt="" width="563"><figcaption></figcaption></figure>

This view shows transaction processing speed across a selected time window.

#### Time to consensus

<figure><img src="/files/U3vW3pF94OL8E64omE4V" alt="" width="563"><figcaption></figcaption></figure>

This screen shows the amount of time in milliseconds between the time that a transaction is submitted to the network, and when it has been accepted by all the consensus nodes. The view can be customized across multiple time windows.

#### Mirror node requests

<figure><img src="/files/wClwj9sZt2L247VAjfNN" alt="" width="563"><figcaption></figcaption></figure>

This view shows request volume across Mirror Node services.

### Console data: nodes

<figure><img src="/files/9GUKUUwSw6MmI5W95R9D" alt="" width="563"><figcaption></figcaption></figure>

The Nodes view shows details for each configured consensus and mirror node, including:

* Node Status (active, inactive)
* Node Type (Consensus, Mirror)
* Cloud Provider
* Cloud Region


# Network Backup and Restore

Overview of the HashSphere network backup and restore processes

HashSphere is resilient by design and avoids single points of failure. HashSphere Managed Service also includes backup and restore to support business continuity.

### Backup Scope

For managed service deployments, the following components are backed up on a scheduled basis:

* Consensus node state
* Mirror node data
* Supporting configurations required for service restoration

Backup data is encrypted at rest in cloud storage in a customer-selected region. Restore uses the most recent snapshot to provision replacement components and rehydrate state.

### Downtime Considerations

Network availability during a restore event depends on several factors, including

* The number of nodes affected
* Cloud provider availability during the restore event
* Whether the restore is for a single node or a full-environment recovery
* Transaction volume on the network

Planned maintenance windows and recovery objectives are defined in your service agreement.

### Recovery Objectives

Recovery objectives such as RPO and RTO targets are defined according to the service contract and deployment architecture. Customers should refer to their service agreement for specific commitments.


# Support Overview

Support is included with [HashSphere Managed Service](/managed-service/architecture-overview).

### Access to the Support Portal

Portal access is granted to designated customer personnel during onboarding.

Support Portal URL: <https://support.hashgraph.com/>

<a href="https://support.hashgraph.com/" class="button primary" data-icon="headset">Open Support Portal</a>

If you need access, contact your HashSphere representative.

### What the portal is for

The portal provides two core services:

* **Knowledge base**: searchable access to Hedera and HashSphere resources
* **Support tickets**: raise, update, and track support requests

The knowledge base aggregates Hedera, Hiero, Hashgraph, and HashSphere resources.

{% hint style="warning" %}
Do not share private keys, seed phrases, or un-redacted secrets in support tickets.
{% endhint %}

### Support landing page

The landing page is the quickest way to search the knowledge base and create tickets.

{% embed url="<https://www.canva.com/design/DAHCiFApBsE/sZlWQG6t1-yiNKsjN-0mmg/view>" %}

Ticketing lets you report issues, communicate with support, and track progress.

### User menu

Clicking on the user icon in the top right gives access to the following options:

<div data-with-frame="true"><figure><img src="/files/DzyD8SAT4jTJXC6Dmi3U" alt="" width="362"><figcaption></figcaption></figure></div>

* **Profile**: customize profile and set up two-factor authentication
* **Requests**: view and manage support requests
* **Contact details**: add a photo and a short bio
* **Change password**: update your portal password
* **Sign out**: sign out of the portal

### Next steps

<table data-card-size="large" data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td align="center"><a href="/pages/VPI3ZXdEHcCUC285TpeH"><mark style="color:$primary;"><strong>Raising Support Tickets</strong></mark></a></td><td><a href="/pages/VPI3ZXdEHcCUC285TpeH">/pages/VPI3ZXdEHcCUC285TpeH</a></td></tr><tr><td align="center"><a href="/pages/VPI3ZXdEHcCUC285TpeH"><mark style="color:$primary;"><strong>Managing Support Tickets</strong></mark></a></td><td><a href="/pages/oflax6xdMks2tdadvibB">/pages/oflax6xdMks2tdadvibB</a></td></tr></tbody></table>


# Raising Support Tickets

### Submit a Request

From any portal page, select **Submit a request** from the top bar:

<figure><img src="/files/463T31rk6WDboMflS0WG" alt=""><figcaption></figcaption></figure>

This opens the ticket creation form.

<figure><img src="/files/qxHnwvNZpdvE5mBLw0Gm" alt="" width="563"><figcaption></figcaption></figure>

Please fill in the fields as follows:

#### Subject

Provide a short, specific title. Keep it searchable.

* `HashSphere issue` is too vague.
* `I’m having difficulty ...` is too long. Save it for the description.
* `Dashboard access from provided link` is just right.
* Prefer a pattern like: `[Mirror Node] 500s on /api/v1/transactions (prod)`

#### Description

Provide enough detail for fast triage and reproduction. Aim to include:

* Description and symptoms of the issue
* The HashSphere components or services that are affected
* How you detected the issue
* What you tried to do to fix the issue, and the results
* The steps to take to recreate the issue
* Any relevant configurations

Include *exact identifiers* when you have them:

* Environment (prod/non-prod) and region
* Timestamps with timezone
* Transaction ID, account ID, contract ID, or topic ID
* Endpoint/URL, request ID, and HTTP status code (if applicable)

{% hint style="warning" %}
Do not share private keys, seed phrases, or unredacted secrets. Redact tokens and passwords.
{% endhint %}

The text entry has comprehensive formatting options, including code lines and code blocks:

<figure><img src="/files/MeM8WsWx6o6L7RBafzI1" alt="" width="563"><figcaption></figcaption></figure>

#### Business Impact

The Business Impact drop-down is used to indicate the urgency of the support ticket.

<figure><img src="/files/3QoICsdmPLnjyDZOievb" alt="" width="563"><figcaption></figcaption></figure>

Use the following guidance when selecting impact:

* **Critical** - Complete service outage or data corruption affecting production operations, causing immediate and severe business disruption with no available workaround.
* **High** - Significant degradation of service performance or functionality in production, substantially impacting business operations with limited or complex workarounds available.
* **Medium** - Partial loss of non-critical service functionality or moderate performance issues causing noticeable but manageable impact to business operations with reasonable workarounds available.
* **Low** - Minor issues or general inquiries about the managed service that have minimal to no impact on business operations or can be addressed through documentation.

#### HashSphere Services Impacted

Select the services impacted by the issue. If you do not see a service, select **Service Not Listed**.

<figure><img src="/files/yB4BGQ3KFjNsnBsZc3MG" alt="" width="563"><figcaption></figcaption></figure>

#### Attachments

<figure><img src="/files/vrYZJ5UOqDW7S5gkl4Oc" alt="" width="563"><figcaption></figcaption></figure>

Attach any files that help diagnose the issue, in particular:

* Log files
* Configuration files
* Crash stack dumps
* Application architecture diagrams

### Submitting Tickets

Select **Submit** to create the ticket. The ticket is routed to a support agent.

<figure><img src="/files/rvXmNK9pUxwFguSd1fWp" alt="" width="158"><figcaption></figcaption></figure>

You will receive a confirmation email.

### Next steps

<table data-card-size="large" data-view="cards"><thead><tr><th align="center"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td align="center"><a href="/pages/VPI3ZXdEHcCUC285TpeH"><mark style="color:$primary;"><strong>Managing Support Tickets</strong></mark></a></td><td><a href="/pages/oflax6xdMks2tdadvibB">/pages/oflax6xdMks2tdadvibB</a></td></tr><tr><td align="center"><a href="/pages/itCVVvzjR4Xd1A8kgfL4"><mark style="color:$primary;"><strong>Support Overview</strong></mark></a></td><td><a href="/pages/itCVVvzjR4Xd1A8kgfL4">/pages/itCVVvzjR4Xd1A8kgfL4</a></td></tr></tbody></table>


# Managing Support Tickets

To view support tickets, select **Requests** from the user menu in the support portal:

<figure><img src="/files/rYU8BONMLNV5dQc5Sz4Y" alt="" width="243"><figcaption></figcaption></figure>

Or select 'My requests' from the landing page:

<figure><img src="/files/2WUZPUkFV4bqHskravkg" alt="" width="563"><figcaption></figcaption></figure>

This will take you to a list of support requests that you’re associated with, including tickets you raised and tickets you were CC’d on:

<figure><img src="/files/gYZZSSXCpTj9y3XwekSY" alt="" width="563"><figcaption></figcaption></figure>

Requests can be searched and sorted by creation date and last activity.

You can filter by **My requests** vs **Requests I'm CC'd on**. You can also filter by status:

* Open
* Awaiting your reply
* Solved

You can also select 'Organization requests' to see requests raised by other members of your organization.&#x20;

### Updating a ticket

When a ticket is selected, you can see the details of the ticket and a chat window for communication with the support team:

<figure><img src="/files/uql2Q3L5acncGeyXJBHO" alt=""><figcaption></figcaption></figure>