OpenClaw Hosting Guide: Setup, Config & Deployment Steps

For an always-on OpenClaw Gateway, use a Linux VPS or cloud VM, optionally run OpenClaw with Docker Compose, keep the Gateway bound to loopback, and connect through SSH or Tailscale. Configure authentication before any non-loopback exposure, persist the state and workspace, back up both, and validate the Gateway, model, Control UI, and channels after deployment.

Hosting OpenClaw means moving the Gateway from a laptop that may sleep or disconnect to a machine that remains available independently. The remote Gateway holds runtime state, channel connections, configuration, credentials, sessions, and the workspace; your browser, phone, SSH client, or messaging app becomes a client of that Gateway.

Key takeaways

• A small Linux VPS is the most flexible default for an always-on personal OpenClaw deployment, while Docker Compose improves repeatability and isolation without being mandatory.
• OpenClaw uses port 18789 by default, generally binds to loopback, and requires token, password, or correctly configured proxy authentication for non-loopback exposure.
• The official Docker guidance identifies 2 GB of RAM as practical for image building; runtime requirements vary with browser automation, media, concurrency, logging, and model workload.
• SSH tunneling or Tailscale Serve usually provides safer remote access than directly exposing the Gateway to the public internet.
• A deployment is not complete until the Gateway, authentication, Control UI, model request, channel transport, restart persistence, backups, and security audit have been tested.

What is OpenClaw hosting?

OpenClaw hosting is the practice of running the OpenClaw Gateway on a server that stays online instead of running the Gateway only on a desktop or laptop. The server becomes the source of truth for Gateway state and workspace, so the client device does not need to remain powered on. The official OpenClaw Linux server documentation describes this VPS model and lists deployment paths for several cloud providers.

A hosted Gateway can maintain messaging-channel connections, receive requests, run configured tools, serve the Control UI, and preserve state between client sessions. Hosting does not automatically make an OpenClaw installation public or secure: those outcomes depend on the bind address, authentication, firewall, channel policies, tool permissions, and persistence design.

Which OpenClaw hosting model should you choose?

The best OpenClaw hosting model depends on whether you value simplicity, control, portability, or operational separation. For most individual users, a conventional Linux VPS is the sensible starting point; Docker is an optional deployment layer rather than a requirement.

User profile	Recommended option	Why it fits	Main drawback
Testing or learning	Local installation	Fastest setup and no server bill	The Gateway is unavailable when the computer sleeps, disconnects, or shuts down
Always-on personal assistant	Small Linux VPS	Persistent runtime, full control, conventional networking, and predictable administration	You must manage patching, firewall rules, backups, and recovery
Repeatable or isolated deployment	Docker Compose on a VPS	Portable files, explicit volumes, reproducible rebuilds, and easier image rollback	Container networking and volume persistence add moving parts
Minimal server administration	PaaS or one-click provider	Faster provisioning and platform-managed restarts	Persistent storage, WebSockets, sleep behavior, networking, and vendor dependence require careful verification
Multiple unrelated users	Separate instance per tenant, or deliberately designed orchestration	Separate credentials, state, workspaces, and authority boundaries	Higher cost and substantially more operational complexity
Advanced platform team	Kubernetes	Declarative operations and multi-instance orchestration	Excessive complexity for most personal OpenClaw deployments

The OpenClaw installation index links to native, VPS, Docker, Kubernetes, provider-specific, and Render deployment paths. A provider appearing in that documentation is a compatibility or deployment reference, not necessarily an endorsement, native image, one-click template, or managed OpenClaw service.

What does an OpenClaw VPS need?

An OpenClaw VPS needs a supported Linux environment, SSH access, persistent storage, firewall controls, credentials for the model provider and any messaging channels, and a separate backup destination. OpenClaw workload requirements are not universal: browser automation, media processing, concurrent users, log volume, plugins, and local inference can change CPU, memory, and storage needs considerably.

• A Linux VPS or cloud VM, preferably using a currently supported Ubuntu or Debian release.
• A non-root administrative user and SSH key access.
• A provider firewall or host firewall that can restrict inbound traffic.
• Docker Engine and Docker Compose v2 if you choose containers.
• Persistent disk space for the OpenClaw state directory, workspace, logs, and any Docker volumes.
• Model or service API credentials, stored as secrets rather than in public shell history or screenshots.
• Credentials for Telegram, Discord, WhatsApp, Slack, or other channels you intend to use.
• A remote backup destination or provider backup system, plus a tested restore procedure.
• A remote-access plan: SSH tunnel, Tailscale, reverse proxy, or intentionally public Gateway endpoint.

The official OpenClaw Docker prerequisites call for Docker Engine or Desktop, Docker Compose v2, sufficient disk, and at least 2 GB of RAM for image building. That 2 GB figure is image-build guidance, not a universal runtime minimum. A 1 GB host may fail during pnpm install with an out-of-memory error, while a larger workload may need more memory after installation.

How do you prepare a Linux VPS?

Prepare the VPS before installing OpenClaw by creating controlled access, applying operating-system updates, enabling a firewall, and deciding how state and backups will be stored.

1. Provision the VM. Record the public IP address, operating system and version, region, SSH key, storage allocation, backup or snapshot options, and infrastructure cost. Do not assume the smallest provider plan will handle every OpenClaw workload.
2. Create or use a non-root administrator. Use SSH keys where possible and reserve root for administrative tasks. Avoid operating the Gateway as an unnecessarily privileged process.
3. Update the host. On Debian or Ubuntu, a generic first pass is:

   sudo apt update && sudo apt upgrade -y

   Package names and commands vary by distribution.

4. Configure the firewall. Allow SSH from trusted addresses where practical. Keep port 18789 private unless you have deliberately chosen an authenticated exposure design. A cloud security group and the host firewall can both matter.
5. Choose persistence. Identify the OpenClaw state directory, workspace, environment file or secret store, and Docker volumes before the first production run.
6. Choose a recovery destination. A snapshot on the same provider is useful, but a separate backup destination protects against account, region, and provider failures.

Swap can help absorb short memory spikes on a small VPS, but swap is not a substitute for adequate RAM. Browser automation, builds, media work, and local model inference can overwhelm a small instance even when the Gateway itself is lightweight.

How do you install OpenClaw natively?

A native installation is usually the simplest path when you want the fewest layers and are comfortable with Node.js, package management, and a system service. The official documentation supports installer-script, npm, pnpm, Bun, source, and other installation methods.

1. Install the official package

The official installer route is:

curl -fsSL https://openclaw.ai/install.sh | bash

Piping a remote script directly into a shell is convenient but requires trust in the URL and the current contents of the script. For a review-first workflow, download the script, inspect it, verify that the URL and contents are the expected official materials, and execute it only after review. A package-manager or source installation may be preferable when you need a more auditable build process.

For a source installation, the official documentation shows:

git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
pnpm ui:build
pnpm link --global
openclaw onboard --install-daemon

2. Run onboarding

Start onboarding with:

openclaw onboard

Use the onboarding flow to configure provider credentials, initial Gateway settings, and a Gateway authentication secret. Treat API keys and Gateway tokens as production secrets: do not commit them to Git, paste them into shared terminals, or include them in screenshots.

3. Install the managed service

On Linux or WSL2, OpenClaw supports a systemd user service. The direct installation command is:

openclaw onboard --install-daemon

If onboarding has already been completed, the service command is:

openclaw gateway install

Verify the service with:

openclaw gateway status

Native startup behavior differs by operating system. OpenClaw documents a systemd user service for Linux and WSL2, a LaunchAgent for macOS, and Scheduled Task or Startup-folder alternatives on native Windows. A VPS deployment normally uses Linux and systemd.

4. Verify the installation

Run the official diagnostic sequence:

openclaw --version
openclaw doctor
openclaw gateway status
openclaw status
openclaw logs --follow
openclaw channels status --probe

The installation verification guidance and troubleshooting documentation distinguish a running process from a successful connectivity probe. Confirm both before calling the deployment healthy.

How do you deploy OpenClaw with Docker Compose?

Docker Compose is useful when isolation, portability, repeatable upgrades, or rebuilds matter. Native installation is often faster for local development, while Docker is a good fit for a server that already runs containers or for a deployment you want to reproduce on another host.

The official Docker setup supports a locally built image:

./scripts/docker/setup.sh

It also supports a pre-built image:

export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./scripts/docker/setup.sh

Common image tags include main, latest, and version tags. The latest tag is not inherently stable or reproducible. For production, pin a tested version or digest, record the version currently running, and document how to return to the previous image.

The setup script runs onboarding, prompts for provider API keys, writes a Gateway token to .env by default, creates an auth-profile secret-key directory, and starts the Gateway through Docker Compose. Inspect the generated Compose file before treating it as a production configuration.

How should Docker state be persisted?

Persist OpenClaw state and the workspace outside the container. Preserve the environment file or use a supported secret-management mechanism. Do not keep the only copy of credentials, configuration, sessions, or workspace files inside an ephemeral container.

The exact host mount paths should be checked against the Compose file and OpenClaw version selected for deployment. Conceptually, the persistence design should look like this:

Host persistent storage
├── OpenClaw state directory
│   ├── configuration
│   ├── credentials and auth profiles
│   └── relevant session state
├── OpenClaw workspace
├── environment file or external secrets
└── backup copy on separate storage

Back up configuration, credentials, workspace content, and relevant session state. Test restoration by creating a clean deployment and confirming that the restored Gateway can start, authenticate, answer a model request, and reconnect the intended channels.

Why is the Docker Control UI unreachable?

A Docker bridge deployment can make the Gateway unreachable when the Gateway listens only on loopback inside the container. Forwarded traffic arrives through the container’s network interface, not its loopback interface. The documented remedies are host networking or changing the bind mode to lan or an appropriate custom 0.0.0.0 address.

The Docker example Control UI address is:

http://127.0.0.1:18789/

That address is appropriate when the port is forwarded to the host and accessed locally or through an SSH tunnel. It is not proof that the Gateway should be exposed directly to the internet.

Where does OpenClaw store its configuration?

OpenClaw reads an optional JSON5 configuration file at ~/.openclaw/openclaw.json. If the file is absent, OpenClaw uses defaults. You can select another path with:

export OPENCLAW_CONFIG_PATH="/path/to/openclaw.json"

The OpenClaw configuration documentation warns against using a symlink for openclaw.json, because OpenClaw-owned writes replace the file atomically rather than writing through the symlink.

The configuration hierarchy separates concerns:

• gateway controls mode, port, bind address, authentication, reload behavior, and remote connectivity.
• agents.defaults controls default agent-loop behavior.
• agents.entries can override supported settings for individual agents.
• Channel settings control account credentials, pairing, direct-message policy, group behavior, and message access.
• Tool settings control execution, elevated access, sandboxing, and permissions.

Inspect settings without exposing secrets in shared output:

openclaw config get gateway.bind
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw config get gateway.mode
openclaw config get gateway.remote.url

Although token inspection can help diagnose a mismatch, never publish a real token or leave it in CI logs, screenshots, shell history, or shared terminals.

What is the minimum safe OpenClaw configuration?

A practical baseline keeps the Gateway on loopback, enables token authentication, separates direct-message sessions by channel and peer, restricts tools, and disables elevated access until there is a documented reason to enable it.

{
  gateway: {
    bind: "loopback",
    auth: {
      mode: "token",
      token: "replace-with-a-long-random-token",
    },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",
      },
    },
  },
  tools: {
    profile: "messaging",
    exec: {
      security: "deny",
      ask: "always",
    },
    elevated: {
      enabled: false,
    },
  },
}

This example comes from the OpenClaw exposure runbook baseline; it is a starting point, not a universal policy. The gateway.auth.token protects the Gateway itself. The gateway.remote.token is a client credential source and does not, by itself, enable local Gateway authentication.

If both token and password credentials exist, set gateway.auth.mode explicitly. Use gateway.auth.mode: "none" only for trusted local loopback use. Non-loopback bindings require a valid authentication path. Public Control UI deployments may also require explicit gateway.controlUi.allowedOrigins.

Generate a Gateway token with:

openclaw doctor --generate-gateway-token

Run security checks before exposing remote access and after changing authentication, bind mode, tools, channel policies, or plugins:

openclaw security audit
openclaw security audit --deep
openclaw health

How should you access a remote OpenClaw Gateway?

Keep the Gateway loopback-bound whenever possible. A loopback listener prevents ordinary internet traffic from reaching the service directly, while an access layer such as SSH or Tailscale provides controlled remote connectivity.

SSH tunnel: the simplest private method

Create a local tunnel from your computer to the VPS:

ssh -N -L 18789:127.0.0.1:18789 USER@SERVER_IP

While the SSH session remains open, visit:

http://127.0.0.1:18789

The local browser connects to its own loopback address; SSH forwards the traffic to the Gateway’s loopback address on the server. Adjust the SSH user and port if your server uses different values.

Tailscale Serve: convenient private remote access

Tailscale Serve keeps the Gateway aligned with a private, loopback-first access model while making the service available to devices in the tailnet. This is convenient for regular personal or team access without opening the Gateway to arbitrary internet clients. The OpenClaw remote-access documentation describes SSH and Tailscale patterns.

Tailscale Funnel is different: Funnel creates public exposure. Treat Funnel as an internet-facing deployment and retain Gateway authentication, origin controls, firewall restrictions, and auditing.

Reverse proxy: for domains, HTTPS, or public ingress

Use a reverse proxy when you need a domain name, HTTPS termination, centralized identity, or a deliberately public service. Configure TLS certificates, WebSocket forwarding, trusted proxy IPs, explicit allowed origins, firewall rules, rate limiting, and access logs.

OpenClaw’s trusted-proxy authentication mode requires you to list only proxies you control in trustedProxies. Do not enable a dangerous Host-header origin fallback merely to bypass an origin error. A public reverse proxy is an advanced architecture, not a replacement for Gateway authentication.

How do you add Telegram, Discord, or WhatsApp?

Add a messaging channel after the Gateway is healthy and authenticated. The official Docker examples include:

# WhatsApp
docker compose run --rm openclaw-cli channels login

# Telegram
docker compose run --rm openclaw-cli channels add 
  --channel telegram 
  --token "<token>"

# Discord
docker compose run --rm openclaw-cli channels add 
  --channel discord 
  --token "<token>"

For a native installation, use the corresponding OpenClaw CLI commands without the Docker Compose wrapper. Adding a channel does not automatically make arbitrary users safe or authorized. Review pairing approval, direct-message policy, group mention requirements, allowlists, account selection, and network egress.

A single shared agent used by several people is shared delegated tool authority, not per-user host isolation. For unrelated customers or high-risk workloads, use separate instances with separate state directories, credentials, workspaces, and preferably separate containers or VMs.

How should OpenClaw hosting be secured?

Security starts with reducing exposure and authority, not with choosing Docker or a particular provider.

• Bind privately. Use gateway.bind: "loopback" unless a non-loopback address is necessary.
• Authenticate explicitly. Use a strong token or password for non-loopback access. A remote client token does not replace Gateway authentication.
• Restrict inbound traffic. Use provider security groups, host firewall rules, private networking, or Tailscale ACLs.
• Control browser origins. Set explicit allowed origins for public or reverse-proxied Control UI use.
• Limit tools. Keep execution denied or confirmation-based until the required commands and users are understood. Keep elevated access disabled unless justified.
• Restrict channels. Pair accounts deliberately, use allowlists where appropriate, and define group and direct-message policies.
• Protect secrets. Rotate Gateway tokens, model keys, channel tokens, and auth profiles after suspected exposure.
• Audit changes. Run the normal and deep security audits before and after exposure or permission changes.
• Harden Docker. Review mounted host directories, avoid unnecessary Docker socket access, and inspect the Docker DOCKER-USER firewall chain on a public VPS.

Docker can improve packaging and isolation, but Docker does not automatically secure a publicly exposed Gateway, weak token, dangerous tool policy, or sensitive host mount. The OpenClaw security documentation and exposure runbook should be treated as deployment references rather than optional reading.

How do backups, updates, and rollback work?

Back up the OpenClaw state directory, configuration, credentials or auth profiles, workspace, and any deployment files needed to recreate the service. Keep at least one backup outside the VPS account or region. A provider snapshot is useful for rapid recovery but is not a complete backup strategy if the provider account or region is unavailable.

A practical update sequence is:

1. Back up state, configuration, workspace, and secrets.
2. Record the current OpenClaw package version or Docker image digest.
3. Apply the new package or pull/build the tested image.
4. Restart the Gateway.
5. Check the service, logs, Control UI, model request, and channels.
6. Roll back to the previous package or image if a critical test fails.

For a native installation, the documented diagnostic ladder is:

openclaw update status --json
openclaw status --all
openclaw gateway status --deep
openclaw doctor --fix
openclaw gateway restart

For Docker, update the pinned image or rebuild from the selected source revision, then run the same functional checks through the container’s CLI service. Do not hard-code a “current” OpenClaw version without checking the official release information immediately before publication. An example image tag is not proof that the tag is the current stable release.

OpenClaw supports hybrid configuration reload behavior, but Gateway binding and port changes require a restart. The OpenClaw FAQ documents the distinction between reloadable configuration and changes that require restarting the Gateway.

How do you validate a production deployment?

Validate the complete path rather than checking only whether a process exists.

1. Check the installed version: openclaw --version.
2. Check configuration and repair suggestions: openclaw doctor.
3. Check the service: openclaw gateway status.
4. Check overall status: openclaw status.
5. Watch runtime logs: openclaw logs --follow.
6. Probe channels: openclaw channels status --probe.
7. Test the Control UI through the actual SSH tunnel, Tailscale address, or reverse proxy that users will use.
8. Test authentication with a valid credential and confirm that an invalid credential is rejected.
9. Test a model request and confirm that the configured provider responds.
10. Restart the service and verify that configuration, credentials, workspace, and channels survive.
11. Test restoration from a backup on a clean or separate deployment.

For a direct Gateway probe, use:

openclaw gateway probe 
  --url ws://127.0.0.1:18789 
  --token "$OPENCLAW_GATEWAY_TOKEN"

Use wss:// for an appropriate public TLS deployment. When an explicit remote URL is supplied, do not assume that credentials stored in local configuration automatically apply to that remote target.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

How do you troubleshoot a hosted OpenClaw deployment?

The openclaw command is not found

Check the Node.js version, global npm prefix, and shell path:

node -v
npm prefix -g
echo "$PATH"

An incorrect global npm path or missing global binary directory can prevent the shell from finding OpenClaw. Add the correct global binary directory to the service user’s path according to the installation documentation.

The Gateway refuses to bind

An error such as refusing to bind gateway ... without auth means the selected non-loopback bind lacks an acceptable authentication path. Configure token, password, or supported proxy authentication before using lan, tailnet, or another non-loopback bind. Do not solve the error by disabling authentication.

Port 18789 is already in use

Check the listener:

lsof -i :18789

An EADDRINUSE error or a message that another Gateway instance is listening indicates a port collision. Stop the duplicate service or select a different configured port, then update the tunnel, proxy, firewall, and client URL consistently.

Authentication keeps failing

Check the configured mode, target URL, token or password, service logs, and paired-device state:

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw gateway status
openclaw logs --follow

Common causes include a wrong or rotated token, token and client drift, an authentication-mode mismatch, stale paired-device credentials, a client using the wrong port, an unapproved browser origin, or a temporary browser-origin lockout after repeated failures.

The Gateway is running but remote clients cannot connect

A running process does not prove remote reachability. Check the actual bind address, host firewall, provider security group, port forwarding, TLS scheme, allowed origins, authentication mode, and whether the client is targeting the local or remote Gateway. A loopback-only service should be reached through the intended SSH or Tailscale path rather than by opening port 18789 publicly.

Channels are configured but do not respond

Run openclaw channels status --probe and openclaw logs --follow, then check bot-token validity, pairing approval, direct-message policy, group mention requirements, channel-account selection, network egress, and the state directory used after restart.

The container restarts and loses configuration

State, credentials, or workspace files were probably stored only inside the container. Compare the Compose volume mappings with the paths OpenClaw actually uses, restore persistent data, restart the stack, and perform a clean restore test before relying on the deployment.

Which hosting providers are worth considering?

No provider is universally best. Compare persistent storage, always-on behavior, WebSockets, outbound networking, firewall and private-network controls, snapshots, restore options, shell or root access, regions, support, and total cost rather than choosing from a marketing label.

Provider or service	Best suited to	Important trade-off	Pricing or availability note
Hetzner Cloud	Cost-conscious technical users wanting a conventional VPS	Requires Linux administration, patching, and backup management	OpenClaw says pricing changes; select a Debian or Ubuntu VPS and scale if memory becomes a problem
DigitalOcean Droplets	Beginners and developers wanting a familiar VPS dashboard	Not fully managed OpenClaw operations and not necessarily the lowest infrastructure price	Check current plan, storage, snapshot, bandwidth, and region pricing before purchase
Hostinger VPS	Less technical users attracted to provider-specific setup flows	Less provider-neutral than a manual installation; template status needs verification	Promotional and renewal prices were not verified in this research pass
AWS EC2 or Lightsail	Existing AWS users needing regions, IAM, networking, and automation	Billing and networking can be unnecessarily complex for an individual deployment	Cost depends on region, instance, storage, data transfer, and backups
Railway or Render	Developers preferring application-style deployment	Verify persistent volumes, sleep behavior, WebSockets, background services, and restart semantics	Current platform pricing and service limits require checking before recommendation
Fly.io	Developers wanting geographic placement and infrastructure-as-code workflows	Platform networking can be harder for beginners than a traditional VPS	Costs depend on machine size, region, storage, and bandwidth
Oracle Cloud	Advanced, cost-sensitive users considering ARM or free-tier capacity	Quota, account, capacity, availability, and support complexity	Free-tier eligibility and regional capacity are not guaranteed
Tailscale	Private remote access to a loopback-first Gateway	Not a substitute for public application hosting or public ingress controls	Check current personal and business plan terms

Infrastructure cost is only one part of the bill. Add model or API usage, persistent volumes, backups, bandwidth and egress, domains and TLS where applicable, monitoring, browser automation or local-inference hardware, and any managed-service premium. A one-click image may automate provisioning without managing API bills, secrets, channel policies, backups, patching, incident response, or migration.

Before selecting managed OpenClaw hosting, verify whether the vendor controls the VPS account, whether shell access is included, where credentials and transcripts are stored, whether backups are included, whether API keys are bring-your-own-key, whether the vendor can access workspace files, how data can be exported, what renewal and cancellation terms apply, and whether the integration is official or a community image.

OpenClaw hosting deployment checklist

• Linux user and SSH key configured
• Operating system updated
• Firewall and provider security group reviewed
• OpenClaw installed and onboarding completed
• Gateway startup service enabled
• Gateway authentication configured
• Gateway remains loopback-bound unless exposure is intentional
• State, credentials, configuration, and workspace persisted
• Separate backup destination configured
• Backup restoration tested
• Control UI reachable through the intended access path
• Model request tested
• Channel probe passes
• Security audit reviewed
• Version or image pin and rollback path documented

Frequently Asked Questions

Is Docker required to host OpenClaw?

Docker is not required to host OpenClaw. A native Linux installation is supported and is often the simplest path, while Docker Compose is useful for isolation, repeatable deployment, portability, and image-based rollback.

What is the safest way to access a hosted OpenClaw Gateway?

The safest general-purpose pattern is to keep the Gateway bound to loopback and access it through an SSH tunnel or Tailscale Serve. Direct public exposure should be reserved for deployments with explicit authentication, origin controls, firewall rules, and security auditing.

How much RAM does an OpenClaw VPS need?

OpenClaw does not have one universal RAM requirement for every workload. The official Docker guidance identifies 2 GB as practical for image building, while browser automation, media processing, concurrency, logs, plugins, and local inference can require more.

Does a VPS price include OpenClaw’s model usage?

A VPS or PaaS bill normally covers infrastructure, not model-provider API consumption. Total cost can also include storage, backups, bandwidth, domains, TLS, monitoring, browser automation, and managed-service fees.

The Bottom Line

A reliable OpenClaw deployment is a persistent, authenticated Gateway with a deliberate access path—not merely a process that happens to run on a VPS. Start with a Linux VPS, use native installation or Docker Compose according to your operational needs, keep access private by default, persist and back up state, and test recovery before relying on the service.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.