Mark an application for permanent deletion at a future date, perfect for ephemeral preview environments and short-lived staging apps. Once a schedule is set, the application page shows a banner with the deletion date, and the settings tab gains a danger-zone card where you can update the date or cancel the schedule entirely.
Owners receive warning emails 7 days and 1 day before deletion, so nothing gets removed by surprise. When the timestamp passes, the application is deleted through the same code path as a manual delete, so there is no special-case cleanup behavior to worry about.
Schedules can only be enabled via the REST API or the ploi.yaml infrastructure-as-code spec (under spec.application.settings.scheduled_deletion_at). After it is enabled, the dashboard can update or cancel it.
Before: Preview and staging apps had to be cleaned up manually, or left running until somebody noticed. After: Set a deletion timestamp via the API or ploi.yaml, get warning emails before it fires, and let the platform clean up automatically.
Cache services now expose the full maxmemory-policy setting, so you can choose how Redis or Valkey behaves when memory fills up. Pick a policy in the create or edit modal and the platform configures the service correctly, including a --maxmemory flag set to 80% of the pod memory limit so eviction kicks in before the kernel kills the container.
The full set of policies is supported (allkeys-lru, allkeys-lfu, volatile-lru, volatile-lfu, allkeys-random, volatile-random, volatile-ttl, and noeviction), each with a description in the dropdown.
Before: Services ran with the default noeviction policy and got OOM-killed when caches filled up.
After: Pick the eviction strategy that matches your workload directly from the service modal.
A new documentation hub at /docs/ai walks you through deploying with AI-assisted tooling end-to-end. Includes dedicated guides for Claude Code, Cursor, and Windsurf, plus a vibe-coding pillar page that covers the full workflow from idea to production.
Each guide explains how to connect the tool to the Ploi Cloud MCP server, what the recommended workflow looks like, and the most useful prompts for deployment, configuration, and troubleshooting.
A new llms-full.txt file is also served at the root, giving AI assistants a single comprehensive reference of every public capability and API endpoint on the platform.
When UpCloud rejects a managed database creation request (for example because of a plan quota or invalid configuration), the underlying reason now reaches both the dashboard error metadata and a Discord notification, instead of being swallowed by a generic timeout message. Logs include the full parsed invalid_params payload so support can diagnose creation failures faster.
A daily check now records the first time a domain's DNS resolves to the platform, and surfaces a notification when SSL provisioning fails afterwards. Helps catch certificate issues early on domains that have just been pointed at the platform.
The Laravel applications doc now explains how to configure the TrustProxies middleware so applications generate correct HTTPS URLs behind the platform's load balancer. This solves the most common cause of broken redirects, asset URLs, and OAuth callbacks for Laravel apps using HTTPS.
The partner program now pays a 5% recurring commission on referred customer revenue. The partners page and program documentation have been updated to reflect the new rate.
Application metrics totals were showing 0 cores and 0 RAM for any application running outside the platform's default cluster (such as the chi1 region). Metrics are now resolved per application region so dashboards, usage details, and the storage monitor all return real data regardless of where the application is deployed.
When duplicating an application, the copied services (databases, caches, etc.) were created but never deployed, leaving the new application without working dependencies. The duplicate flow now dispatches deployment jobs for every non-worker service so the duplicated application is ready immediately.
The getting-started card on the application page was hard-coded to either Laravel or WordPress, so Craft CMS, Statamic, Node.js, and generic PHP applications all rendered the WordPress description. Each application type now shows its own copy.
If a managed database or object storage creation failed mid-flight, the platform left a placeholder row that blocked any further managed service creation across the team because of a unique-constraint collision. The placeholder column is now nullable, so a failed attempt no longer blocks subsequent ones.
Documentation page titles containing an ampersand (for example 'Octane & FrankenPHP') were rendering as 'Octane & FrankenPHP' in production due to double-escaping. Titles now pass through component boundaries unchanged and only escape at the final render.