FAQ

Frequently asked questions

Practical short guides for service setup, access, and common customer actions.

> How to generate a public SSH key in a terminal

Create a public SSH key for secure VPS access. Share only the public key with Cli>_; keep the private key on your device.
faq/how-to-generate-a-public-ssh-key

The public key is shared, the private key stays with you

Paste only the public key into checkout or service setup. The private key stays on your computer and is never sent to support or entered into a web form.

Steps

  1. Open a terminal on your computer.
  2. Run: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Confirm the file location or choose a custom path. Never send your private key.
  4. Show the public key with: cat ~/.ssh/id_ed25519.pub.
  5. Copy the full line starting with ssh-ed25519 and paste it into the SSH public key field during checkout or service setup.

Windows 10/11 PowerShell

  1. Open PowerShell or Windows Terminal.
  2. Run: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Press Enter to save the key to C:\Users\your-user\.ssh\id_ed25519, or enter a custom path.
  4. If Windows asks for a passphrase, use one you can store safely, or press Enter to skip it for simple service setup.
  5. Show the public key with: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copy only the full line starting with ssh-ed25519. Do not copy or upload the private key file.
> How to create an SSH key graphically in Windows

Create an SSH key pair in Windows with a graphical tool and share only the public key with Cli>_.
faq/how-to-create-an-ssh-key-graphically-in-windows

Use a Windows tool and paste only the public key

You can create an SSH key pair visually with a Windows SSH client such as PuTTYgen. Cli>_ only needs the public key. Keep the private key on your computer and never upload it through a web form.

Steps

  1. Install PuTTY, or open PuTTYgen if it is already installed.
  2. Choose EdDSA/Ed25519 if available, otherwise choose RSA 4096.
  3. Click Generate and move your mouse over the empty area until the key appears.
  4. Add a passphrase if you want extra local protection for the private key.
  5. Store the private key on your device and keep it confidential.
  6. Copy the public key text and paste it into the SSH public key field in Cli>_.
> Bring your own domain – own your brand

Learn how to point your own domain or subdomain to a CLIopen service before activating Bring your own domain.
faq/bring-your-own-domain

What this setting does

Bring your own domain lets your service respond on your personal hostname, e.g., app.example.com, instead of the default generated *.co.cliopen.cloud. Your DNS must point to CLIopen first, so the hostname can be safely used by the service.

Before you begin

  1. Choose the exact hostname you want, such as app.example.com. Using a subdomain is the simplest option.
  2. Log in to your domain registrar’s DNS management console or your DNS provider’s dashboard.
  3. Delete any conflicting A, AAAA, CNAME, ALIAS, or redirect records for that hostname before adding the CLIopen entry.
  4. Keep the auto‑generated CLIopen hostname active until your custom hostname is verified and fully functional.

Recommended DNS setup for a subdomain

Create DNS records for the exact hostname you’ll enter in CLIopen. For app.example.com the DNS label is app. Point it to the CLIopen ingress addresses supplied by CLIopen support or in your service docs. If your provider asks for a record type, use an A record for IPv4 and an AAAA record for IPv6 when those addresses are provided.

Example:

app.example.com.  A     <CLIopen IPv4 address>
app.example.com.  AAAA  <CLIopen IPv6 address, if available>

When CLIopen provides a CNAME target

Some services give you a generated hostname like service.customer.co.cliopen.cloud. If your service instructions explicitly require a CNAME, create a record such as app.example.com CNAME service.customer.co.cliopen.cloud. Use CNAME only for subdomains, not for the apex/root domain, unless your DNS provider supports ALIAS or ANAME flattening.

Using the root domain

For a bare domain like example.com, most DNS providers don’t allow a standard CNAME. Use A/AAAA records pointing to the CLIopen ingress addresses, or use your provider’s ALIAS/ANAME feature if CLIopen supplied a hostname target.

Delegating an entire sub‑zone

If you want CLIopen to manage records under a sub‑zone such as apps.example.com, create NS records for that sub‑zone pointing to the CLIopen nameservers you received. Don’t change the nameservers for the whole domain unless you intentionally want CLIopen (or another DNS service) to manage all records.

Verification checklist

  1. Allow time for DNS propagation. Small changes often appear within minutes, but some providers cache longer.
  2. Confirm the hostname resolves to the CLIopen target, not to a previous provider.
  3. Enter the exact hostname in the Bring your own domain field—omit `https://` and any path.
  4. After updating, test `https://app.example.com` in your browser.
  5. Keep old DNS records only if they don’t conflict with the new hostname.
> How to transfer a DNS zone to CLIopen

Delegate a domain to ns1.cliopen.com and ns2.cliopen.com so CLIopen can publish records for the whole zone.
faq/transfer-dns-zone-to-cliopen

What zone transfer means here

For customer DNS, transfer means changing the authoritative nameservers at your domain registrar. After delegation points to CLIopen, records added in CLIopen DNS are published by our authoritative nameservers.

Before changing nameservers

  1. Copy existing DNS records you still need, such as website, mail, verification, SPF, DKIM, DMARC, and service records.
  2. Add the zone in CLIopen DNS. If delegation is not ready yet, CLIopen saves it but does not activate it for customers until validation passes.
  3. Create the required records in CLIopen DNS before switching nameservers when possible.

Delegate the zone

  1. Open your registrar domain settings for the domain, for example example.com.
  2. Find Nameservers, DNS delegation, or Authoritative DNS settings.
  3. Replace the current nameservers with ns1.cliopen.com and ns2.cliopen.com.
  4. Save the change and wait for registry and resolver propagation.

Validation

Return to CLIopen DNS and click Recheck delegation. When public NS records show ns1.cliopen.com and ns2.cliopen.com, the zone is queued for synchronization and records become live from CLIopen.

> Guide: Account registration and login

Account registration and login: Create one customer account for orders, billing details, DNS, and service management. Use an email address that your team can keep access to.
faq/account-registration-and-login

What to know

Create one customer account for orders, billing details, DNS, and service management. Use an email address that your team can keep access to.

Customer steps

  1. Register with your working email address.
  2. Confirm the email message if confirmation is requested.
  3. Complete account and billing details before ordering paid services.
  4. Enable two-factor authentication when it is available for your account.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Prepaid credit and daily service cost

Prepaid credit and daily service cost: Prepaid credit shows your visible balance, estimated runway, each active service daily cost, when to top up, and the suspension or visible deletion deadline risk.
faq/prepaid-credit-how-it-works

What to know

Cli>_ uses prepaid credit for eligible services. Active services consume credit over time, so the visible balance, runway estimate, daily service cost, top-up timing, and visible deletion deadline on a suspended service help you understand how long services can keep running.

Customer steps

  1. Add credit from the customer area.
  2. Review the displayed price and daily service cost before confirming an order or change.
  3. Watch the credit runway indicator, low-balance warnings, suspension notice, and any visible deletion deadline.
  4. Top up before credit is depleted to avoid suspension and later deletion.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Billing periods and credit burn

Billing periods and credit burn: Monthly estimates use 31 days, yearly estimates use 372 days, and prepaid credit burns daily after an order or change is confirmed, paid if required, and applied.
faq/billing-periods-and-credit-burn

What to know

Monthly estimates use 31 days and yearly estimates use 372 days. Prepaid services burn credit by active daily use, selected CPU, RAM, storage, and paid options; a resource change alters daily burn only after it is confirmed, paid if required, and applied.

Customer steps

  1. Compare the 31-day monthly estimate and 372-day yearly estimate with the daily credit burn before ordering.
  2. Check whether each resource change increases or reduces the active daily cost.
  3. Confirm and pay the order or change when payment is required, then wait until it is applied.
  4. Save invoices, order confirmations, and visible credit history for accounting.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Order status and payment confirmation

Order status and payment confirmation: Orders may wait for payment provider confirmation before service activation starts. A pending order is not proof of failure, so avoid duplicate orders unless the first order is clearly expired or cancelled.
faq/order-status-and-payment-confirmation

What to know

Orders may wait for payment provider confirmation before service activation starts. A pending order is not proof of failure, so avoid duplicate orders unless the first order is clearly expired or cancelled.

Customer steps

  1. Return from the payment provider page to Cli>_ when payment is complete.
  2. Check whether the order is pending, confirmed, expired, cancelled, or failed.
  3. Avoid creating a duplicate order while provider confirmation may still arrive.
  4. Contact support with the order number and payment provider reference if available.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Information needed for service setup

Information needed for service setup: Service setup commonly needs the service name, domain or DNS plan, storage and resources, access or admin email, and SSH public key, never secrets.
faq/service-setup-information-needed

What to know

Most services need customer choices such as service name, domain, DNS readiness, storage size, CPU or RAM resources, access or admin email, and SSH public key. Providing accurate public values prevents delays; passwords, private keys, tokens, and database exports should not be entered into setup fields.

Customer steps

  1. Read the product form before checkout and prepare every requested public value.
  2. Prepare the service name, exact domain, DNS tasks, storage or resource choices, access or admin email, and SSH public key before ordering.
  3. Use clear service names that your team can recognize.
  4. Avoid entering passwords, private keys, tokens, or secret exports into fields that ask for public values.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Changing service resources after order

Changing service resources after order: Change existing service resources only after checking the new price, daily credit burn, confirmed/paid/applied timing, restart or downtime risk, and export needs.
faq/change-service-resources-after-order

What to know

Change resources from the existing service instead of creating a duplicate new-service order. CPU, RAM, storage, backup retention, Offsite Archive retention, price, and daily credit burn can change, and the request takes effect only after it is confirmed, paid if required, and applied. Some changes need maintenance, restart, or downtime, so export important data before a risky change.

Customer steps

  1. Open the existing service and review current CPU, RAM, storage, backup retention, and Offsite Archive retention.
  2. Choose the resource change you need and check the new price and daily credit burn.
  3. Confirm and pay the change when required, wait until it is applied, and read any maintenance window, restart, or downtime notice.
  4. Export important data and confirm the change only when your team is ready.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Cancelling a service and data retention

Cancelling a service and data retention: Cancelling a provisioned service suspends it first, shows the exact visible configurable deletion deadline, then purges after lifecycle timing; backups and Offsite Archive are separate.
faq/cancel-service-and-data-retention

What to know

Cancelling a provisioned service suspends it first and shows the exact visible configurable deletion deadline before permanent purge after the lifecycle timing expires. Pending unpaid unprovisioned orders may deactivate without the same runtime data lifecycle, while backups and Offsite Archive copies follow separate retention rules.

Customer steps

  1. Create your own export before cancellation or prolonged credit depletion.
  2. Read the suspension notice, configurable timing, and exact visible deletion deadline shown for the service.
  3. Remember that backup retention and Offsite Archive retention are separate from lifecycle deletion and purge.
  4. Contact support before the deletion deadline if the order is pending, unpaid, unprovisioned, or you need help deciding.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Backups and restore requests

Backups and restore requests: Backup retention depends on product options; backups are for operational recovery, restores can overwrite newer data, and requests need order number, time, and context without secrets.
faq/backups-and-restore-requests

What to know

Backup retention depends on the selected product and options. Backups are for operational recovery, are not export or archive replacements, and a restore can overwrite newer data. A useful restore request names the service, order number, approximate restore time, and visible error or context without passwords, private keys, tokens, or secret database content.

Customer steps

  1. Check the backup retention option on the product or service.
  2. Keep separate exports for business-critical data and long-term archives.
  3. Ask support for restore options with the service name, order number, approximate restore time, and visible error or context.
  4. Do not send passwords, private keys, tokens, or secret data with a restore request.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: What Offsite Archive is for

What Offsite Archive is for: Offsite Archive keeps remote archive copies in another datacenter. It is separate from short operational backups and from lifecycle deletion timing, and it is not live application storage. Billing is based on stored data over time: stored MB multiplied by days stored, shown as EUR/GB/month and rounded to whole cents.
faq/offsite-archive-purpose

What to know

Offsite Archive keeps remote archive copies in another datacenter. It is separate from short operational backups and from lifecycle deletion timing, and it is not live application storage. Billing is based on stored data over time: stored MB multiplied by days stored, shown as EUR/GB/month and rounded to whole cents.

Customer steps

  1. Use Offsite Archive for retained archive copies, exports, and older material, not active app storage.
  2. Choose retention days that match your compliance or recovery goal.
  3. Estimate MB-days from stored MB multiplied by days stored.
  4. Review the rounded monthly archive cost when stored data or retention grows.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Choosing VPS CPU, RAM, and disk size

Choosing VPS CPU, RAM, and disk size: Choose VPS CPU, RAM, and disk from the workload profile, database, cache, logs, expected growth, and headroom. Swap, OOM, out of memory, process killed messages, and sustained load are signs the plan may be too small; Cli>_ can help interpret visible symptoms.
faq/vps-cpu-ram-and-disk-sizing

What to know

Choose VPS CPU, RAM, and disk from the workload profile, database, cache, logs, expected growth, and headroom. Swap, OOM, out of memory, process killed messages, and sustained load are signs the plan may be too small; Cli>_ can help interpret visible symptoms.

Customer steps

  1. Start with the smallest size that satisfies vendor requirements, workload, database, cache, logs, and expected traffic.
  2. Increase RAM when OOM, out of memory, process killed messages, or heavy swap appear.
  3. Increase CPU for sustained compute, compression, builds, or busy application workers.
  4. Increase disk before filesystem usage is critical, leaving room for growth, logs, and backups.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: VPS public IP options

VPS public IP options: Use a dedicated public IP when an external provider or firewall needs a stable outbound source allowlist, inbound access, ports, or DNS names.
faq/vps-public-ip-options

What to know

A dedicated public IP is useful when external partners, providers, or firewalls need a stable allowlist address. Confirm whether the allowlist is for inbound traffic, outbound source traffic, or both; DNS names and required ports only are usually easier to manage.

Customer steps

  1. Ask the external partner or provider whether inbound, outbound source allowlist, or both directions are required.
  2. Use DNS names instead of numeric addresses where possible.
  3. Open only the application ports you actually need in the inbound firewall.
  4. Share the allowlist requirement with support before changing access design.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Shared SSH access for VPS

Shared SSH access for VPS: Shared SSH access uses ssh -p <port> <username>@<public-host> with the visible username, host, and assigned port from the service page. Your private key stays on your device and is never needed by support.
faq/shared-ssh-access-for-vps

What to know

Shared SSH access uses ssh -p @ with the visible username, host, and assigned port from the service page. Your private key stays on your device and is never needed by support.

Customer steps

  1. Copy the SSH username, host, and port exactly as shown.
  2. Connect with ssh -p <port> <username>@<public-host> from your local terminal.
  3. Use your private key locally; never paste the private key into chat or tickets.
  4. Share only the service name, public host, port, username, and visible error if connection fails.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Custom domain readiness checklist

Custom domain readiness checklist: Confirm registrar or nameserver authority, exact hostname, apex or subdomain type, CNAME/A/AAAA/ALIAS/ANAME support, and no conflicting records.
faq/custom-domain-readiness-checklist

What to know

A custom domain must point to the service target before final testing. Confirm that the registrar and authoritative nameservers are the place you will edit DNS, choose the exact hostname, decide whether it is an apex domain or subdomain, remove conflicting records, and use CNAME, A/AAAA, ALIAS, or ANAME according to DNS provider support.

Customer steps

  1. Choose the exact apex domain or subdomain, such as example.com or app.example.com.
  2. Confirm registrar or nameserver authority and remove conflicting records for the same hostname before adding the new target.
  3. Use CNAME, A/AAAA, ALIAS, or ANAME only where your DNS provider, registrar, and hostname type allow it.
  4. Wait for DNS propagation and certificate checks before switching production traffic.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: DNS record types for services

DNS record types for services: Service DNS commonly uses A/AAAA, CNAME, MX, TXT, and CAA records; mail TXT values include SPF, DKIM selector records, and DMARC on _dmarc.
faq/dns-record-types-for-services

What to know

Common service DNS records include A record, AAAA, CNAME, MX, TXT, and CAA. Web traffic, mail routing, SPF, DKIM selector records, DMARC on _dmarc, verification, and certificate policy use different record types; CNAME conflicts with other records on the same hostname, and wrong CAA values can block certificate issuance.

Customer steps

  1. Copy the service-provided DNS type and target exactly.
  2. Use A/AAAA for addresses, CNAME for allowed subdomain aliases, MX for mail, and TXT for SPF, DKIM, DMARC, or verification.
  3. Put DKIM under the provider selector and DMARC under _dmarc for the sending domain.
  4. Use CAA carefully because wrong values can block certificate authorities.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: DNS propagation and TTL

DNS propagation and TTL: DNS propagation depends on TTL values and resolver cache behavior, so there is no fixed promise for exact propagation time. Old and new answers can coexist across resolvers until caches expire even after the authoritative record is changed.
faq/dns-propagation-and-ttl

What to know

DNS propagation depends on TTL values and resolver cache behavior, so there is no fixed promise for exact propagation time. Old and new answers can coexist across resolvers until caches expire even after the authoritative record is changed.

Customer steps

  1. Lower TTL before a planned change if your DNS provider allows it.
  2. Make the DNS change once and avoid repeated edits while caches expire.
  3. Test from more than one resolver or network when answers differ.
  4. Share the old answer, expected answer, hostname, TTL, and change time with support.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Planning Nextcloud storage

Planning Nextcloud storage: Nextcloud storage planning must include user files, shared folders, deleted files, version history, sync overhead, and expected growth. Running close to the limit can break uploads and sync.
faq/nextcloud-storage-planning

What to know

Nextcloud storage planning must include user files, shared folders, deleted files, version history, sync overhead, and expected growth. Running close to the limit can break uploads and sync.

Customer steps

  1. Estimate current user files and shared folders before ordering.
  2. Add headroom for deleted files, version history, previews, and sync activity.
  3. Review storage usage with your team before large imports.
  4. Increase storage before users hit the limit or sync clients start failing.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Migrating repositories to Gitea

Migrating repositories to Gitea: Plan Gitea migration around Git LFS, submodules, protected branches and tags, deploy keys, tokens, webhooks, CI/CD, and verification clone/push tests.
faq/gitea-repository-migration

What to know

Gitea migration is more than copying Git history. Plan repository owners, teams, Git LFS, submodules, protected branches, protected tags, remote URLs, webhooks, CI/CD, deploy keys, and old access tokens before the cutover. Do not reveal token values; rotate or recreate tokens safely after migration.

Customer steps

  1. List repositories, owners, collaborators, Git LFS objects, submodules, protected branches, protected tags, and automation users.
  2. Mirror or export repositories from the old provider and verify branches and tags.
  3. Update developer remote URLs, CI/CD integrations, webhooks, and deploy keys, then verify clone, push, Git LFS, submodules, and CI behavior.
  4. Rotate or revoke old access tokens after the migration is confirmed without sharing token values.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Listmonk sender domain basics

Listmonk sender domain basics: Listmonk delivery works best when the sender domain has correct DNS records, a From identity, SPF, DKIM, DMARC alignment, bounce or Return-Path handling, and unsubscribe and identity details. Publish SPF at the mail-provider location, DKIM with the provider selector, and DMARC on _dmarc. Send test messages before a real campaign and do not share mail secrets.
faq/listmonk-sender-domain-basics

What to know

Listmonk delivery works best when the sender domain has correct DNS records, a From identity, SPF, DKIM, DMARC alignment, bounce or Return-Path handling, and unsubscribe and identity details. Publish SPF at the mail-provider location, DKIM with the provider selector, and DMARC on _dmarc. Send test messages before a real campaign and do not share mail secrets.

Customer steps

  1. Choose a sender domain or subdomain dedicated to campaigns and set the From identity.
  2. Publish verification DNS, SPF, DKIM, and DMARC records requested by your mail provider.
  3. Send test messages before a real campaign and check spam placement, bounce behavior, Return-Path, and links.
  4. Keep unsubscribe, List-Unsubscribe, and sender identity details accurate without sharing secrets.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Classic hosting runtime settings

Classic hosting runtime settings: Classic Hosting auto mode detects and builds PHP, Node.js, Java, Python, .NET, Go, and Ruby projects. Manual mode is first-class for Nginx, Apache, and FrankenPHP; the PHP version selector applies where supported and does not mean every FrankenPHP case receives the same selector. CPU, RAM, memory, storage, backup retention, Offsite Archive retention, uploads, cache, and logs affect cost and operation. Test the application after deployment.
faq/classic-hosting-runtime-settings

What to know

Classic Hosting auto mode detects and builds PHP, Node.js, Java, Python, .NET, Go, and Ruby projects. Manual mode is first-class for Nginx, Apache, and FrankenPHP; the PHP version selector applies where supported and does not mean every FrankenPHP case receives the same selector. CPU, RAM, memory, storage, backup retention, Offsite Archive retention, uploads, cache, and logs affect cost and operation. Test the application after deployment.

Customer steps

  1. Choose auto mode for detected builds or manual mode for Nginx, Apache, or FrankenPHP runtime control.
  2. Select PHP 8.2/8.3/8.4 only where the chosen runtime supports that selector.
  3. Size CPU, RAM, memory, storage, backup retention, and Offsite Archive retention for traffic and data.
  4. Test uploads, cache, logs, and visible application errors after deployment.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.

> Guide: Safe information to share with support

Safe information to share with support: Support can help faster when you provide customer-facing context without exposing secrets. Safe details include order numbers, visible service names, domains, public hosts and ports, selected runtime, PHP version, CPU, RAM, storage, backup retention, Offsite Archive retention, uploads, cache, logs, approximate time, masked screenshots, and visible error text. Never send passwords, private keys, tokens, seed phrases, full logs with secrets, database exports, or internal infrastructure details.
faq/support-safe-information-to-share

What to know

Support can help faster when you provide customer-facing context without exposing secrets. Safe details include order numbers, visible service names, domains, public hosts and ports, selected runtime, PHP version, CPU, RAM, storage, backup retention, Offsite Archive retention, uploads, cache, logs, approximate time, masked screenshots, and visible error text. Never send passwords, private keys, tokens, seed phrases, full logs with secrets, database exports, or internal infrastructure details.

Customer steps

  1. Include the order number, visible service name, domain, approximate time, and public host or port when relevant.
  2. For hosting issues, include runtime mode, language or PHP version, CPU, RAM, storage, backup retention, Offsite Archive retention, uploads, cache, logs, and what changed recently.
  3. Attach screenshots only after hiding passwords, tokens, private keys, sessions, and personal data.
  4. Never send secrets, generated configuration files, internal names, internal IP addresses, or full dumps with sensitive values.

Safe support note

Share only customer-facing names, order numbers, domains, screenshots with secrets hidden, and visible error text. Do not share passwords, private keys, tokens, generated configuration files, or internal infrastructure details.