No. Every config block is generated by plain JavaScript in your browser. Log paths, cron commands, unit names and server details never leave your machine.
Four everyday server tools in one page: build a logrotate policy that stops disks filling at 3 AM, calculate real monthly bandwidth from your traffic, convert any cron job to a systemd timer with Persistent=true, and convert chmod numeric and symbolic permissions both ways — with WordPress and CMS recommended values. Built entirely in your browser.
Rotating logs before the disk fills, guessing how much bandwidth a site
really needs, migrating cron jobs to systemd timers with the
Persistent catch-up flag nobody remembers, and decoding whether
chmod 755 is safe for a WordPress uploads directory.
Each of these is five minutes of work with the right reference in
front of you — and an outage when it is done from memory. This
toolkit generates the exact config or number for all four, annotated
with what goes where and why.
Every byte is produced by JavaScript in your browser. Log paths, cron commands and domain details are never uploaded.
Paste log paths, pick frequency and retention, add compress and postrotate reload.
Enter page size and monthly views — get GB/month, average Mbps and a plan tier.
Paste any 5-field cron line — get OnCalendar syntax plus the .service/.timer pair.
Type 644 or rw-r--r-- in either direction — get commands and CMS recommended values.
copytruncate vs postrotate-reload: copytruncate works without a reload but can lose lines written in the copy window; the reload path is lossless when the app supports it. Do not use both for the same log.
Both calculators ignore protocol overhead and concurrency spikes — treat the results as the floor, not the ceiling. The results block shows hosting plan tiers and the 95th-percentile billing note.
Supported: *, steps (*/n), ranges (a-b), comma lists, day names in the output, and @daily/@weekly/@monthly/@hourly/@yearly shortcuts. @reboot maps to a boot-time unit — the output explains it.
The output converts your mode both ways, decodes each r/w/x triplet, explains special bits (4000 suid, 2000 sgid, 1000 sticky) when present, and emits find-based commands that set different modes for files and directories — the part everyone gets wrong with chmod -R.
Increase/decrease swap offline: the script swaps off (moving pages back to RAM — make sure free RAM covers it), rebuilds the file at the new size, and swaps back on. Never fallocate/truncate a live swap file; never use dd on ZFS/btrfs-rooted systems (the output notes the ZFS exception).
Output is a single drop-in file at /etc/sysctl.d/99-systron-tuning.conf plus the apply and verify commands. Every line is commented with what it changes and when it helps — nothing is applied silently.
Output includes the fstab line, the create-mountpoint + mount -a test sequence (systemd automounts on boot read the same file), and the findmnt/df verify commands. The nofail flag option is in the notes — use it for removable/network disks so a dead disk cannot hang boot.
Output is an sshd_config.d drop-in + the strict test order: sshd -t, then keep the current session open and confirm a NEW login works before closing it. Enable key-only only after your key is installed and tested.
The journal grows until capped — on a small VPS an uncapped journal is a disk-full outage waiting to happen. Output: the drop-in conf, the immediate vacuum commands to shrink the existing journal, and the disk-usage verify.
Too many open files is the classic high-traffic app failure: the OS default is 1024. Output covers all three layers that must agree — the kernel (fs.file-max), PAM limits.conf, and the systemd override (LimitNOFILE) for services, plus the per-process check commands.
Output: the jail.local drop-in, the log-path notes for the chosen jail, and the fail2ban-client status/verify commands — including unban.
Order matters: allow SSH BEFORE enabling, or you lock yourself out. Output includes the check-then-enable sequence and the list/verify commands for both frontends.
Output: user creation with or without a shell, the sudoers drop-in (never edit /etc/sudoers directly — visudo syntax check included), the sshd_config.d AllowUsers reminder, and the key install with correct .ssh permissions (700/600 — the #1 cause of key auth failures).
Output: the .service unit, the enable/verify sequence, and the journal debugging commands — plus the wanted-by explanation (multi-user.target vs timers).
Output: the hostnamectl commands, the /etc/hosts entries, the resolved.conf drop-in, and the 127.0.0.53 stub explanation with resolv.conf compatibility — the full chain that breaks when they disagree.
Output: the lsblk identification step, wipefs warning gate, parted mklabel/mkpart commands, mkfs, mount + fstab cross-link, and the exact resize path if you grow the disk later.
Output: mdadm --create, the mdadm.conf persistence step, cat /proc/mdstat monitoring, degraded-array boot warning, plus replace-failed-disk and remove-array sequences. RAID is not backup.
Output: cryptsetup luksFormat, luksOpen, mkfs on /dev/mapper/…, the crypttab + fstab pairing, optional keyfile auto-unlock, header backup, and a blunt warning: losing the header or passphrase loses the data. All generated locally — your passphrase is never typed into this page.
Everything above runs in JavaScript in your browser. Log paths, cron commands and server details you enter are never uploaded.
| Decision | Default in the output | Why |
|---|---|---|
| Logrotate compression | compress + delaycompress | delaycompress keeps the newest rotation readable for one cycle — the one you are most likely to debug. |
| Log reopen strategy | postrotate reload (copytruncate optional) | Lossless for reload-aware apps; copytruncate trades a small loss window for zero-downtime simplicity. |
| Timer persistence | Persistent=true | Cron silently skips missed runs after downtime; a persistent timer runs the missed job at next boot. |
| Timer unit pair | separate .service + .timer files | The timer starts the service; keeping them separate lets you also run the job manually with systemctl start. |
| Bandwidth headroom | 30% | Traffic is spiky: caches expire together, bots crawl in bursts, a post goes viral. Plan for the spike, not the mean. |
| chmod files vs dirs | 644 files, 755 dirs | Directories need +x to be enterable; files need it only to execute. chmod -R 755 over a web root makes every file executable. |
| wp-config.php | 600 (or 400) | Contains DB credentials and salts — the web server user only needs to read it, never write. |
| Never 777 | Flagged in every CMS preset | World-writable files are the first thing attackers and malware scanners look for — and it usually means a wrong ownership, not a missing permission. |
| Special bits | Decoded when present (4755 etc.) | suid/sgid/sticky have real security consequences — the output explains what each one means before you use it. |
No. Every config block is generated by plain JavaScript in your browser. Log paths, cron commands, unit names and server details never leave your machine.
With plain compress, the file rotated today is already gzip by tomorrow — and the one you need to read during an incident is always the newest rotation. delaycompress holds the previous cycle uncompressed and gzips it only on the next rotation, so the freshest log stays readable with standard tools, at the cost of one cycle of disk space.
When the writing application keeps a file handle open and never reopens it on signal — some Node.js, Java and containerized apps do this. A normal rotation renames the file and the app keeps writing into the renamed inode, so the new file stays empty. copytruncate copies then truncates in place, no reload needed — the trade-off is a small window where lines can be lost. Try the postrotate reload first; only fall back to copytruncate when the app cannot reopen.
Three reasons. Persistent=true: if the machine was off at the scheduled time, the timer runs the missed job at the next boot — cron just skips it. Logging: output goes to the journal, so you read failures with journalctl -u myjob.service instead of hunting mail. Dependencies: units can require network-online.target or order after a mount, which cron has no way to express.
All the common shapes: exact times, steps (*/5), ranges (0 9-17 * * 1-5), comma lists, day names in the output, and the @daily/@weekly/@monthly shortcuts. The genuinely untranslatable corners are rare (cron day-of-month AND day-of-week OR semantics — the output warns when your expression uses both) and nonstandard 6-field Quartz syntax. Every generated OnCalendar line comes with a systemctl calendar verification command so you confirm the next runs before enabling anything.
The last triplet — other users. 755 lets anyone enter the directory and read files; 750 restricts both to the owner and the group. For web roots served by a single nginx/Apache user, 750 with the web server in the group is tighter and works fine; use 755 when shared hosting runs PHP as your own user, or static assets must be readable by arbitrary CDN pull processes.
Directories 755, files 644, and wp-config.php at 600 — owned by your user with the web server able to read them. Never 777 anywhere: if an installer demands it, the real problem is ownership (files owned by root while PHP runs as www-data). The chmod tab presets emit the exact find-based commands: directories get 755, files get 644, in two lines that never make a file executable. Uploads, themes and plugins follow the same 755/644 split — the only special case is wp-config.php, which drops to 600 because it holds database credentials and salts.
Take your average page transfer size from DevTools (not the file sizes on disk — compression matters), multiply by monthly pageviews, add 30% headroom for spikes and growth, and that is your GB/month floor. The calculator also converts it to average Mbps and suggests a plan tier. Two caveats it flags: video and large downloads dominate totals far beyond pageviews, and bandwidth billed at the 95th percentile is about sustained spikes, not totals.