Chapter 09

Limits and reference

The numbers you will eventually hit, and a table for when something is not behaving.

Request and upload limits

Setting Value What hitting it looks like

Maximum upload size 64M Large uploads rejected by the web server before PHP sees them

POST body size 64M Same, for form submissions

Maximum execution time 60s Long request killed mid-flight

Request timeout at the web server 60s A 504 even if PHP is still working

Maximum input variables 5000 Very large forms silently truncated

Default memory limit 256M Fatal "allowed memory size exhausted" — adjustable per site

Session lifetime 7200s Users signed out after two hours idle

Setting	Value	What hitting it looks like
Maximum upload size	64M	Large uploads rejected by the web server before PHP sees them
POST body size	64M	Same, for form submissions
Maximum execution time	60s	Long request killed mid-flight
Request timeout at the web server	60s	A `504` even if PHP is still working
Maximum input variables	5000	Very large forms silently truncated
Default memory limit	256M	Fatal "allowed memory size exhausted" — adjustable per site
Session lifetime	7200s	Users signed out after two hours idle

Both timeouts are 60 seconds, so anything genuinely long-running belongs in a queue worker rather than a web request. Only the memory limit is adjustable per site.

PHP environment

Version: PHP 8.3, served by php-fpm behind nginx.
Extensions: mysql, mbstring, xml, bcmath, curl, zip, gd, redis, opcache, intl
Tooling: Composer, git, unzip, and the PHP CLI are available inside the container.
Timezone: UTC. Set your application's own timezone in its configuration if you need another.
Error display: Off. Errors are logged to the container output, never rendered to visitors.
Opcache: Enabled, and does not re-check file timestamps. Restart the site after deploying PHP changes.
Concurrency: Up to 20 PHP worker processes per site, recycled every 500 requests.

Paths

Site folder: /var/www/virtual/<your-domain>/ — identical inside and outside the container
Docroot, static image: the folder itself
Docroot, PHP image: <folder>/application/public
App root, PHP image: <folder>/application — the deployed app (repo contents, vendor/, artisan); wiped and re-published on each deploy
Durable data, PHP image: <folder>/storage (Laravel storage tree) and <folder>/.env (secrets) — kept outside application/ and symlinked into it, so they survive a re-publish
Background programs: <folder>/application/.nimbus/supervisor/ — only boot.conf, queue-worker.conf, scheduler.conf
Health endpoint: /health — reserved; do not define a route at this path

Service addresses

MySQL: mysql:3306 — version 8.0. Database and credentials are provided by your operator.
Redis: redis:6379 — version 7. Persistent, does not evict; set expiry on cache entries.
Your site: no-<domain-with-dashes> on the internal network, port 80. No published host ports.

Troubleshooting

Symptom Most likely cause

Deployed a fix, old behaviour persists Opcache. Restart the site — see chapter 04.

Edited a Blade template, old markup still renders Also opcache. The compiled template keeps the same filename, so the cached copy wins. Restart the site.

Page says "image OK (no app deployed)" Nothing at the docroot. On the PHP image your entry point must be at application/public/index.php.

Status is Up but the site errors Expected — the health check never runs your app. Check the container logs.

Blank 403, no styling Your IP address is not unlocked. See chapter 08.

Certificate warning or HTTPS failure after publishing DNS not resolving to the box yet, so the certificate is still pending. On a dev box, an untrusted authority is normal.

App cannot connect to the database The database or user was probably never created — the panel does not create them.

Queue worker not running Filename must be exactly queue-worker.conf; then restart the site. Check the log for a SKIPPED line.

Worker rejected on start Invalid INI, a non-program section, or user= set to something other than www-data.

Uploads fail over ~64 MB The upload limit. Not adjustable per site.

Request dies at 60 seconds Execution or gateway timeout. Move the work to a queue.

Assets stale after deploy Static files carry a one-year immutable cache header. Fingerprint asset filenames.

Symptom	Most likely cause
Deployed a fix, old behaviour persists	Opcache. Restart the site — see chapter 04.
Edited a Blade template, old markup still renders	Also opcache. The compiled template keeps the same filename, so the cached copy wins. Restart the site.
Page says "image OK (no app deployed)"	Nothing at the docroot. On the PHP image your entry point must be at `application/public/index.php`.
Status is Up but the site errors	Expected — the health check never runs your app. Check the container logs.
Blank 403, no styling	Your IP address is not unlocked. See chapter 08.
Certificate warning or HTTPS failure after publishing	DNS not resolving to the box yet, so the certificate is still pending. On a dev box, an untrusted authority is normal.
App cannot connect to the database	The database or user was probably never created — the panel does not create them.
Queue worker not running	Filename must be exactly `queue-worker.conf`; then restart the site. Check the log for a `SKIPPED` line.
Worker rejected on start	Invalid INI, a non-program section, or `user=` set to something other than `www-data`.
Uploads fail over ~64 MB	The upload limit. Not adjustable per site.
Request dies at 60 seconds	Execution or gateway timeout. Move the work to a queue.
Assets stale after deploy	Static files carry a one-year immutable cache header. Fingerprint asset filenames.

What this platform does not do

Stated plainly, so you can plan around it rather than searching for a setting that is not there:

No deploy pipeline, git integration, or build step. Files are copied in and the site is restarted.
No database or user provisioning. Ask your operator.
No custom environment variables beyond the settings an image declares.
No wildcard certificates. Every domain needs its own DNS record.
No backups of your site folder as part of the platform. Confirm with your operator what is backed up.
No self-service accounts, password reset, or email — credentials are handed to you directly.
No log viewer in the panel. Logs are read from the box.

Designed but not built

The project has designs for in-container CI that would deploy on push and reload PHP for you, and for automatic banning of probing addresses. Neither exists in the running platform. If you come across them in the project's design documents, read them as intent rather than as behaviour you can rely on.