Skip to main content

Remote deployments

Local deployment engine

In the current desktop source, deployments open in Local mode and need no LaraEnv account or plan. Configuration and history stay on your computer; detect, apply, deploy and activity actions connect directly to your selected SSH host. Release 0.5.7 and earlier images may show the previous cloud-only model.

Overview​

Deploy a Laravel, Node, or static app to a remote server tied to one of your saved SSH hosts. LaraEnv drives the whole lifecycle and shows step-by-step output for every action.

Create a local destination and select a saved SSH host before starting. Local operation does not require enabling cloud integration. The source repository and offline guide describe this account-independent model.

Lifecycle​

Detect​

Scans the remote server — OS family/version and installed software — and saves a detection profile that informs the rest of the workflow.

Apply​

You provide the settings:

  • Git repo URL and branch
  • Domain and SSL
  • Environment variables
  • PHP version
  • Database
  • A deploy preset

LaraEnv then configures the server: clones the repo, bootstraps the database, builds assets, writes the web server config, and more — with step-by-step output.

HTTPS

Let's Encrypt HTTPS can be provisioned during apply so your domain is served over SSL.

Deploy​

Runs the deploy on the configured server.

Destroy​

Executes the removal plan on the remote host and removes the local registration after success. If remote removal fails, the registration and attempt result remain available.

Delete record removes only the local registration and its history; it does not tear down the server.

Remote database access​

Allow remote database access is off by default for MySQL and PostgreSQL. Enable it in Apply and enter individual IPv4 or IPv6 addresses separated by commas or lines. Hostnames, wildcards, and CIDR ranges are not accepted.

This requires an active UFW firewall; LaraEnv adds source-specific rules and does not enable UFW for you. A provider firewall may also need the same allowed-source rules. Apply can restart the shared database service to change its listener.

Use a dedicated database user for each deployment. The application keeps its local connection. Reapplying with access off revokes the accounts and rules managed for that deployment; unrelated rules are preserved. The shared listener remains remote-capable while another managed deployment needs it. Changing this option takes effect on Apply, not on each automatic Git pull.

See the public database access guide for credentials, PostgreSQL provisioning, and cleanup details.

Activity log​

The desktop stores local configuration and history under <LaraEnv root>/state/deployments/, protected by Windows DPAPI independently of the cloud account. It retains the latest 100 runs per destination, with up to 4 MiB per log and an indication when output is truncated. Preserve the complete data folder for backup; copying it to another Windows profile can leave records locked.

An active run is marked interrupted after the desktop process closes. Check the remote server before repeating it: an interrupted local record does not undo SSH commands already sent. The desktop does not automatically repeat commands if remote execution finished but saving the local result failed.

Existing hosted deployments​

Existing hosted records are not automatically converted or executed. After explicitly enabling cloud integration and signing in, you can choose a hosted destination for import and map it to a local SSH host. User-provided JSON import is also available in Local → Import JSON. Import creates local records without executing scripts or opening SSH; conflicting data preserves the existing local version. Hosted history can provide summaries without complete old log bodies.

One operation at a time can modify a server from this desktop process across local and cloud modes. Other desktop processes, computers and TUI sessions do not share that lock.

Data preservation​

Your .env file and storage\ directory survive a re-apply. They are kept across runs via a safe keep directory, so application data and configuration aren't lost when you apply again.

See also Deploy presets and SSH hosts.