> For the complete documentation index, see [llms.txt](https://docs.reachplatform.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reachplatform.com/customizations-and-bolt-ons/bolt-ons-catalog/custom-app-hosting.md).

# Custom App Hosting

Decide whether Reach or your team hosts and releases the web and mobile front ends.

### Overview

Custom App Hosting defines who owns, deploys, and operates the customer-facing web and mobile applications.

* **What it is:** hosting ownership for the customer-facing **web** and **mobile app** layer
* **Why teams use it:** align **deployment**, **releases**, and **operational ownership**
* **Who it is for:** brand teams responsible for **digital operations**, **release management**, and **support readiness**

<a href="https://datami.atlassian.net/helpcenter/Boltons/portal/1488/group/1848/create/2353" class="button primary" data-icon="cart-shopping">Buy this bolt-on</a>

### At a glance

It applies to:

* **Web** browser experience
* Mobile apps on **iOS** and **Android**

It does **not** affect backend ownership.

Reach continues to own and operate:

* **Core platform services**
* **APIs**
* **Billing, provisioning, and system logic**

{% hint style="info" %}
Unless explicitly agreed otherwise, all brands launch under a Reach-hosted model.
{% endhint %}

### Hosting models

#### Reach-hosted

Reach owns and operates the front-end applications.

* **Deployment** is managed by Reach
* Releases follow **shared platform release cycles**
* **Monitoring, uptime, and incident handling** are managed by Reach
* Updates are aligned with **platform-wide changes**

#### Brand-hosted

The front end is deployed and operated independently.

Full ownership includes:

* **Deployment**
* **Release management**
* **Monitoring and uptime**

Integration with Reach **backend APIs** remains unchanged.

This model requires **operational readiness** on the brand side.

### Typical use cases

* Fastest launch with minimal operational overhead
* Existing web or app platform already in place
* Need for an independent release cadence
* Preference for Reach-managed operations

### When each model is used

| Scenario                                      | Recommended model |
| --------------------------------------------- | ----------------- |
| Fastest launch with minimal overhead          | Reach-hosted      |
| Existing web or app platform already in place | Brand-hosted      |
| Need for an independent release cadence       | Brand-hosted      |
| Preference for managed operations             | Reach-hosted      |

### Ownership boundary

| Layer                      | Ownership                      |
| -------------------------- | ------------------------------ |
| Frontend, web and app UI   | Reach or Brand, based on model |
| Backend services           | Reach                          |
| APIs and integrations      | Reach                          |
| Billing and provisioning   | Reach                          |
| App store presence, mobile | Configurable                   |

### Scope

#### Included

* Definition of the **hosting and release ownership model**
* Clear **responsibility split** across teams
* Operational alignment across:
  * **deployment**
  * **release**
  * **escalation**

#### Not included

* Changes to **backend ownership**
* **Net-new custom front-end builds**
* Functional changes to the mobile app beyond **configuration**

### Mobile app in the Reach-hosted model

Reach can create and publish a **brand-specific instance** of the standard mobile application.

#### What this means

* **Core app functionality** remains unchanged
* **Stability and performance** are maintained
* Only **branding and configuration layers** are customized

### Mobile app setup flow

{% stepper %}
{% step %}

#### App instance creation

A **dedicated instance** is created from the shared app framework.
{% endstep %}

{% step %}

#### Branding application

Supported branding includes:

* **Logo**
* **Colors**
* **Banners**
* **Supported UI components**

The brand provides:

* **Final assets**
* **Brand guidelines**
  {% endstep %}

{% step %}

#### App store ownership

Publishing can be done under:

* **Reach developer account**
* **Brand developer account**
  {% endstep %}

{% step %}

#### Store listing preparation

This includes:

* **App icon**
* **Screenshots**
* **Feature graphics**
* **Store descriptions**

Ownership is shared across **design from Reach** and **content from the brand**.
{% endstep %}

{% step %}

#### Marketing and communication readiness

Prepare go-live communication, including:

* **App store links**
* **Email or API-driven messaging**
  {% endstep %}

{% step %}

#### Submission and review

Reach submits the app after approval.

Typical review timeline: **4–7 business days**, depending on platform.
{% endstep %}
{% endstepper %}

### Release and change management

#### Reach-hosted

* Releases follow the **shared cadence**
* Changes are bundled with **platform updates**

#### Brand-hosted

* Releases are controlled **independently**
* Coordination is required for **backend dependencies**

### Key considerations

Hosting model impacts:

* **Release speed**
* **Operational ownership**
* **Support model**

Brand-hosted requires:

* **Monitoring capability**
* **Incident response setup**
* **Defined on-call ownership**

Functional changes to mobile apps require **separate scoping**.

### Brand inputs

* Preferred **hosting model** and rationale
* Surfaces in scope:
  * **Web**
  * **iOS**
  * **Android**
* **Target launch timeline**
* **Desired release cadence**
* Operational readiness, if brand-hosted:
  * **Monitoring**
  * **Support**
  * **Incident response**
  * **On-call contacts**
* Constraints:
  * **Domains**
  * **App store ownership**
  * **Release approvals**
* **Designated approval owner**

### Requesting this bolt-on

For the standard request process, commercial notes, and support, see [Bolt-ons catalog](/customizations-and-bolt-ons/bolt-ons-catalog.md).

### Technical details

For the implementation-specific setup details, visit: [App set-up technical details](https://reachplatform.gitbook.io/reachplatform-docs/technical/~/revisions/b3C3M4tkkLMyqmMcGAsL/bolt-on-setup/custom-app-hosting)

### Frequently asked questions

#### Can we change the hosting model later?

Yes. Reach scopes the operational and release impacts first.

#### What happens after we purchase?

Reach confirms the hosting model and required brand inputs.

<a href="https://datami.atlassian.net/helpcenter/Boltons/portal/1488/group/1848/create/2353" class="button primary" data-icon="cart-shopping">Buy this bolt-on</a>

{% hint style="info" %}
Questions or clarification? Reach out to your respective account manager or email us at <account-desk@reachplatform.com> for help and support.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.reachplatform.com/customizations-and-bolt-ons/bolt-ons-catalog/custom-app-hosting.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.