Applications Center

Deploy Node.js, Laravel & PHP apps

Application provisioning runs through a root agent with a closed, validated action set — unit names are derived in-daemon and prefix-locked, and toolchains run as the tenant Linux user.

Node.js

Node.js applications

Provision a Node app end-to-end and manage its lifecycle from the panel.

Scaffold + write a 0600 env file (write-only; never returned by any read path)
Tenant-scoped npm install / build
Fixed-template systemd unit, prefix-locked name
Reverse proxy to 127.0.0.1:<port>
Start / stop / restart / status / logs / teardown

app detail

app: my-node-app

runtime: node

state: running

proxy: 127.0.0.1:39114

unit: np-tenant-mynodeapp.service

Laravel

Laravel applications

A PHP application path with a guarded artisan surface.

Composer install as the tenant
Fixed artisan sub-command allowlist (no free-form artisan/composer)
current/.env, key:generate, optional migrate & storage:link
Per-tenant PHP-FPM pool running as the tenant user
nginx public/ docroot with try_files → index.php
Optional queue worker + scheduler cron

app detail

app: shop-api

runtime: laravel

php-fpm: pool=shop-api (tenant)

queue: php artisan queue:work

schedule: php artisan schedule:run

How provisioning stays safe

Derived, prefix-locked units

systemd unit names are derived in-daemon from a validated username + slug + kind — never supplied by the panel.

Runs as the tenant

Toolchains and PHP-FPM pools run as the tenant Linux user, isolating app workloads from each other.

Redacted logs

Captured output is secret-redacted and line-capped before it's stored or returned.

Deploy your first app in alpha

Test Node.js or Laravel deployment in a supervised alpha environment.

Request Private Alpha Access View Docs