Cookie settings

We use cookies

Necessary cookies keep the website working and store your choice. With your consent, we can also use functional cookies to remember the theme preference and analytics cookies to measure website usage.

You can accept optional cookies all at once, reject them, or choose individual categories. You can change your consent later; details are available in the Cookies Policy.

LaraDep Documentation

You are reading Self-hosted mode

Self-hosted onboarding and preflight checklist

Detailed self-hosted rollout plan: runner host, SSH keys, known hosts, tags, rollback, and run evidence. You operate the instance, so operational control is yours.

Self-hosted onboarding and preflight checklist

Self-hosted mode gives maximum flexibility and full responsibility. This is an operational checklist for safe rollout after installation and before the first production run.

Purpose and audience

For teams that want full control, this page sets a practical acceptance standard before first run: what must be ready, what can fail, and what must be approved.

Prerequisites

  • Application is running (Docker/Sail), DB and Redis are available,
  • runner host has required tools (Ansible, PHP),
  • SSH key is present on runner host and its fingerprint is trusted,
  • relevant playbooks/files exist for the chosen stack.

Pre-production steps

  1. Check runner host — PHP, Ansible, writable storage/app/ansible-runtime, and `.ssh` access.
  2. Validate target servers — DNS, firewall, SSH access (user/port/key), and maintenance readiness.
  3. Import template through the onboarding flow or existing workspace template import.
  4. Pick a safe initial tag set — recommended: init,web,tls,db,deploy.
  5. Run preflight and resolve all actionable warnings.
  6. Execute first run in a controlled window with monitoring prepared.
  7. Validate target health — DNS, web app, DB and HTTPS readiness, logs.
  8. Run post-review and record outcome in run notes.

Self-hosted checklist

  • Do you have a host key rotation/refresh workflow?
  • Is server SSH access configured via credential or `ssh_key_name`?
  • Is rollback path planned and communicated before first deployment?
  • Are project and server variable scopes assigned correctly?
  • Does run history contain enough metadata for review and audit?

Common mistakes

  • Missing SSH key on runner host or key mismatch,
  • No host key pinning strategy,
  • Running first production run before checklist completion,
  • Runtime drift due to inconsistent variable or file scope changes.

Cross-track references

After first run, continue with self-hosted day-to-day operations, workspace access and isolation, and templates and workflow. If your operational model changes, review mode migration.

Next steps

Next step: Finish with governance checklist before your next change.

Subscribe to our Newsletter

Stay updated with our latest news and articles by subscribing to our newsletter.

Esc Close