A platform is only as consistent as the habits of the people who create environments on it. When one team's environment has backups and alerts and another's does not, the difference shows up at 3 am. The marketplace's add-ons are the fix, provided someone decides which ones are standard. This post is a platform team's checklist for every environment on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic, with the reasoning for each item.
The team runs about sixty environments for a software company we will call Larkspur Digital, across PHP, Node.js, Java and database stacks. The list below is applied to every new environment as part of its creation ticket, and the team audits existing environments against it quarterly. The anchor of the list is the Load Alerts to Slack package, because an environment nobody hears from is the one that fails quietly.
The checklist
| # | Add-on | Applies to | Why it is standard |
|---|---|---|---|
| 1 | Let's Encrypt Free SSL | Every environment with a custom domain | Trusted HTTPS with automatic renewal; no expiry incidents |
| 2 | Database Backup/Restore to a Backup Storage node | Every environment with a database | Scheduled consistent dumps off the database's own disk |
| 3 | Load Alerts to Slack | Every production environment | Platform alerts reach the channel the team watches |
| 4 | NGINX Safe Reload | Every NGINX balancer or NGINX PHP layer | Config edits validated before reload; no dropped connections |
| 5 | Env Start/Stop Scheduler | Every non-production environment | Off outside working hours; billed for disk only |
| 6 | TimeZone Change | Environments whose logs or cron are read by humans in one timezone | Logs and schedules in local time where that matters; UTC otherwise |
| 7 | File Synchronization | Horizontally scaled PHP or Node.js layers without shared storage | Uploads identical on every node |
| 8 | Node.js and NPM Installer | PHP or Java layers that build front-end assets | Node tooling on a non-Node stack, without a second server |
Items one and two: the ones nobody argues about
Every environment with a custom domain gets the Let's Encrypt add-on on the layer that terminates TLS, and the team's monitoring checks certificate expiry externally as a belt to the add-on's braces; it has never fired. Every environment with a database gets the backup add-on with a schedule matched to the data's recovery point objective, dumping to a Backup Storage node that is its own container on its own host. The team runs one Backup Storage node per region and points every environment in that region at it. These two are on the creation ticket as blockers: an environment is not handed over until both are green.
Item three: alerts where people look
The platform creates default load alerts on every container for RAM, CPU, disk, inodes and network, and sends them by email. Email is where alerts go to be ignored. The Load Alerts to Slack package forwards the alerts for the environments you select to a Slack incoming webhook, formatted with environment, node, metric, threshold and current value. Larkspur's channel is #platform-alerts, and because the payload is Slack's, the same package posts into the company's Mattermost, which accepts Slack-format webhooks. The team tunes thresholds in the dashboard's load-alert settings (RAM or CPU above 80% for ten minutes, disk above 85%) so the channel stays quiet enough to be read. A quiet channel that is trusted beats a busy one that is muted, and the team reviews the alert list quarterly for noise.
Item four: never break NGINX with a typo
An NGINX configuration edit followed by a restart has two failure modes: a syntax error takes the site down, and a restart drops in-flight connections. The NGINX Safe Reload add-on adds a one-click action to NGINX layers that runs the syntax test first and, only if it passes, sends a graceful reload so new workers start with the new configuration while old workers finish their requests. If the test fails, the running configuration stays untouched and the error is reported. Larkspur's engineers are told to use the action, never a manual restart, and the team calls it from scripts through the platform API after automated configuration pushes.
Item five: off by default
Every environment tagged staging, QA, demo or personal gets the Start/Stop Scheduler with the team's standard weekday schedule. A stopped environment bills for disk only and starts in under a minute with everything intact. This item cut Larkspur's non-production spend by more than half, which is described in detail elsewhere on this blog, and it is on the checklist because the saving only happens if it is applied to every environment, not the ones someone remembered.
Items six to eight: the situational ones
Timezone. The team's rule is UTC everywhere by default, because distributed systems and databases are happier that way. The exception is environments whose cron schedules and logs are read by a specific office: a nightly report that must run at 02:00 in Singapore, a log a Frankfurt team tails. For those, the TimeZone Change add-on sets the operating-system zone on every node of the layer, including nodes added later by scaling, and restarts cron so schedules follow. It changes how the system displays time, not stored timestamps.
File Synchronization. When a PHP or Node.js layer scales past one node and the application writes uploads to local disk, the add-on installs lsyncd on every node and mirrors changes between them within seconds over rsync and SSH, with new nodes receiving the current file set and joining the mesh automatically. It is the answer when shared storage is more than the application needs; the team uses shared storage or GlusterFS for large or write-heavy file sets and lsyncd for the rest.
Node.js and NPM Installer. A PHP application whose front end is built with a Node toolchain, or a Java node that runs a JavaScript build step, needs Node without being a Node application server. The add-on installs the chosen Node.js version and npm into an existing layer's containers, so npm run build works in a deploy hook and finishes before traffic arrives. Re-running it switches versions.
How the checklist is enforced
Two ways. The environment creation ticket has the eight items as checkboxes with "not applicable" as an allowed answer that must be justified. And because the platform's API lists an environment's installed add-ons, a weekly script compares every environment against the checklist and posts the gaps to the same Slack channel as the alerts. In the first quarter it found eleven environments without backups and four production environments without alert forwarding. In the fourth quarter it found none, which is the point.
Frequently Asked Questions
Can the checklist be applied automatically at creation?
Partly. Clone new environments from a template environment that already carries the add-ons, and the clone inherits them. Add-ons that need per-environment input, such as the Let's Encrypt domain or the backup schedule, still need a value, which the creation ticket supplies.
Does Load Alerts to Slack work with Microsoft Teams or Discord?
Not directly; it posts Slack's payload format. Teams and Discord accept incoming webhooks with different payloads. An n8n workflow on the platform can receive the Slack-format post and translate it, or you can use the platform's email alerts with a mail-to-channel integration.
Why is the Traffic Distributor not on the list?
Because it is a design choice, not a hygiene item. It belongs in front of environments that need canary releases, A/B tests or failover between two backends, and this blog covers those cases separately. The checklist is what every environment needs regardless of its architecture.
Hear from every environment before it fails
Install Load Alerts to Slack and the rest of the checklist from the MassiveGRID PaaS marketplace in a few clicks per environment, and let the platform's per-minute statistics tell your channel when something is running hot. Free 14-day trial, no credit card.
Load Alerts to Slack on MassiveGRID PaaS