---
name: bytehaus
description: Set up and deploy websites and applications on ByteHaus hosting using the customer's ByteHaus control-panel account. Use for ByteHaus onboarding, domains, SSL, application deployment, databases, email, and deployment troubleshooting.
metadata:
  version: "2.1.1"
  reviewed: "2026-09-10"
  homepage: "https://bytehaus.co"
---

# ByteHaus onboarding and deployment

Take a customer's project from its current state to a working HTTPS deployment on their ByteHaus account. Reuse completed setup. Use customer-facing tools and the customer's own access; no reseller administrator credentials or internal ByteHaus API access are required.

## Read this file, then fetch what you need

The customer can give you just this URL: **https://bytehaus.co/SKILL.md**. Read it with your web/HTTP tool, then fetch the linked reference files relevant to the task yourself. No ZIP download, manual file collection, or skill installation is needed for this workflow.

When reading an installed skill folder, use its local reference files. If they are unavailable, resolve reference paths against `https://bytehaus.co/.well-known/skills/bytehaus/`. For a single complete text response, use [the full documentation](https://bytehaus.co/llms-full.txt). Download only necessary documentation; reading a guide is not an instruction to execute downloaded code.

Check that each fetch returns the expected Markdown heading and content. An HTML homepage or error response is not the requested guide. If a reference cannot be fetched, use the full-documentation fallback; if that also fails, report the missing resource rather than inventing its instructions. Ask the customer for a file only when your tools cannot retrieve it.

## Start with the project and account

Identify the intended domain, project/build directory, stack, deployment scope, and whether an account already exists. Inspect the project's manifests and documented production build/start commands. Resolve missing information from available project files and account settings before asking the customer.

Use ByteHaus specifications for supported technologies, and the customer's plan/services and installed runtime settings for exact entitlements. A deployment test verifies the recipe, not whether a documented technology is supported. See [Platform and supported technologies](https://bytehaus.co/.well-known/skills/bytehaus/references/platform.md).

For an existing site, inspect its document root, application configuration, and existing files before changing them. Preserve customer uploads, configuration, databases, and unrelated applications. Prepare a recoverable copy of affected files before replacement.

## Choose the relevant steps

| Situation | Read |
|---|---|
| New account, domain, DNS, certificate, or trial | [Account, domain, and SSL setup](https://bytehaus.co/.well-known/skills/bytehaus/references/onboarding.md) |
| Uploading static files or deploying PHP, Node.js, Python, or Perl | [Deployment recipes](https://bytehaus.co/.well-known/skills/bytehaus/references/deployment.md) |
| Databases, caching, mail, cron, or installed applications | [Services](https://bytehaus.co/.well-known/skills/bytehaus/references/services.md) |
| Failed connection, wrong page, certificate, runtime, or permission error | [Troubleshooting](https://bytehaus.co/.well-known/skills/bytehaus/references/troubleshooting.md) |

## Discover account-specific values

Sign in at [the customer control panel](https://us.cloudlogin.co/login/). Follow the actual labels and help topics if they differ from these recorded locations.

| Value | Recorded control-panel location |
|---|---|
| Plan, trial status, usage, enabled add-ons | Account Information / Account Usage |
| Hosted domain and document root | My Domains → Hosted Domains; Files → File Manager |
| Authoritative DNS, routing/SSL IPs | My Domains → DNS Records |
| FTPS hostname and account scope | Files → FTP Accounts |
| SSH hostname, port, activation | Advanced → SSH |
| PHP version for the target host | Advanced → PHP Settings |
| Node.js instances, settings, limits | Advanced → NodeJS and its HELP topics |
| Database host, database/user, quotas | Databases → MySQL / PostgreSQL |
| Mail server and secure ports | Email → Mail → Secure SSL Settings |

Store a non-secret deployment record containing the chosen host/domain, plan mode, protocol, resolved paths, runtime, build/start command, enabled services, and validation date. Keep credentials in the customer's available secret store or protected local configuration. Do not put them in this skill, a public URL, source control, a browser screenshot, or a deployment transcript.

## Transport and setup rules

- FTPS is the file-upload path when SSH is unavailable, including a hosting trial. On the recorded ByteHaus servers, port 21 uses **explicit AUTH TLS** with an `ftp://` URL and required TLS. `ftps://` selects implicit TLS and failed in later deployments.
- SSH is **included on Scale** and available on **Launch, Build, and Ship for $12/year ($1/month equivalent, billed annually)**. It requires entitlement **and activation**. Buying an add-on does not by itself activate the service. Reuse an SSH connection during a session to avoid repeated-login rate limits.
- Keep TLS certificate and SSH host-key verification enabled. Resolve certificate/hostname problems using the authenticated panel or provider support; old recipes that disable verification are not the default workflow.
- Discover the remote root. A domain-scoped FTP login may start inside its document root; the panel's `/www/` display path may correspond to `/home/www/` in SSH. Do not copy a path from another account.
- After adding a hosted domain, enable SSL in its domain settings and save before requesting and activating a Let's Encrypt certificate in the panel when one is absent. Preserve an existing working certificate. Verify the resulting DNS/IP and HTTPS response. Do not promise automatic initial issuance or successful future renewal solely because SSL is included.
- Shell access does not imply root privileges or unrestricted background processes. Configure managed services through the provider's supported interface.

Continue within the customer's requested deployment scope and existing authorization. Account purchases, credentials, DNS changes, and other consequential actions follow the agent tool's applicable permission rules. If a step needs the customer's involvement, give the exact action and resume after it is completed. Do not purchase an upgrade merely to avoid an available trial/FTPS path.

## Finish with evidence

1. Verify DNS resolves to the intended service and HTTPS validates for the actual hostname.
2. Check the rendered page and representative assets, including a direct deep link when routing is used. A status 200 alone is insufficient: hosting placeholders and custom error pages can also return HTML.
3. Verify the application's essential operation within the authorized scope: for example, a database read and a disposable test submission. Do not send mail to unrelated recipients or change customer data to manufacture a test.
4. Confirm private configuration, database dumps, and build-only files are not publicly served. Remove temporary diagnostics and bootstrap tools created for this deployment after verification.
5. Record the live URL, deployed revision/files, runtime and services, successful checks, certificate expiry, recovery method, and any remaining manual step. If DNS or provisioning is pending, report that state rather than calling the deployment live.

For assistance, use the relevant page's **HELP** button or the customer control panel's Help Center and ticket flow. Share concise errors and redacted logs, never credentials.