# strackt — Full Content > Long-form content from every public page on strackt.io, concatenated for AI grounding crawlers. > Index lives at [/llms.txt](https://strackt.io/llms.txt). Each page is also reachable at its own URL with a `.md` suffix. --- # About strackt ## Home URL: https://strackt.io > strackt manages servers you own. Connect any VPS, deploy your app from Git, we handle deployment, security, updates, and rollbacks. Flat €4 per app, first one free. ### Your servers. Our problem. Managed applications on your own servers. Connect your repo, deploy your app, we handle the rest. _The Four Promises_ ## Everything a managed platform promises. Nothing it takes away. ### Convenience **Your code runs. You keep building.** Connect your repository. We detect your stack. Push your code, it's live. Security patches, updates, configuration — handled automatically. Continuously. ### Freedom **Your infrastructure, your choice.** Any VPS provider. Any region. Your data stays where you put it. Configuration travels with you as code. SSH in anytime. Leave anytime. ### Cost **Flat-rate. Predictable. No surprises.** No usage-based billing. No compute surcharges. No bandwidth overages. Pick your own VPS, pay a flat per-application rate. Know exactly what you'll pay. _Cost equation: €4.50 (Hetzner VPS) + €0 (strackt) = €4.50 /mo total_ ### Confidence **Move fast. There's always a safety net.** Every change creates a checkpoint. Roll back in seconds. Rebuild from scratch in minutes. Ship on Friday. _Where we fit_ ## The only platform that fully manages servers you own. | | Your VPS | Their cloud | |---|---|---| | **You maintain it** | Forge, Ploi, RunCloud — Provision once. Maintain it yourself. | DIY on AWS/GCP | | **They maintain it** | strackt — Managed applications on your own servers. Flat-rate pricing. | Laravel Cloud, Vercel, Railway — Great experience. Their infrastructure. Usage-based pricing. | _How It Works_ ## Connect. Deploy. Forget about it. ### Step 1: Connect your repo Point at your Git repository. We detect your stack automatically. ### Step 2: Your app goes live Add your VPS and we'll move your app over. Don't have one yet? Start on Layover while you get set up. ### Step 3: Push and deploy Push code, we deploy. Zero-downtime. Automatic. ### Step 4: We handle the rest Security patches, updates, configuration enforcement. Continuously. _Capabilities_ ## Everything you need to ship with confidence. ### Stack Detection **Connect your repo. We handle the rest.** Framework, runtime version, database, cache, queue workers, scheduler — detected automatically from your codebase. No forms to fill out. ### Any Provider **Your infrastructure, your choice** Hetzner, DigitalOcean, Vultr, AWS — connect any VPS. Your data stays where you put it. ### Automated Security **Patches applied, not just reported** Security updates applied automatically and safely. No more "restart required" sitting for months. ### Instant Rollback **Roll back any change in seconds** Every change creates a checkpoint. Rebuild from blueprint in minutes. Ship on Friday. > **Your servers. Your provider. Your data. Our problem.** — Early access opens mid-2026. Invite-based, small cohort, hands-on onboarding. → [What to expect](/early-access) > > _No card. No charge. Leave anytime._ --- ## What is strackt? URL: https://strackt.io/what-is-strackt > strackt is a managed server platform on infrastructure you own. Like a caretaker for your apps — we deploy, patch, monitor, recover. You keep ownership of the servers and the keys. ### You have an app. You want it running. That's where it starts. The question is: who manages the infrastructure underneath? Here's a story about houses, caretakers, and sleeping well at night. Every app needs a place to live — a computer that runs it, day and night. In the tech world, that computer is called a **server**. When you want your app running, you have three options. Each one involves a trade-off between experience, ownership, and cost. strackt exists because we think you shouldn't have to choose. _The three options_ ## Rent, DIY, or get a caretaker. ### Rent an apartment _Convenient, but not yours_ You move into a big building someone else owns. The landlord handles maintenance, repairs, security — everything. Very convenient.But it's their building, their rules. They decide the price. They can change the terms. You can't drill into the walls. And if you want to leave, you can't take the apartment with you. > In tech: This is a managed platform like Laravel Cloud or Vercel. Great experience, but their infrastructure, their pricing, their rules. ### Buy a house, do it all yourself _Yours, but exhausting_ You buy your own house. Full control. Your walls, your paint, your rules. Freedom feels great.But then the roof leaks. The locks need changing. The garden's overgrown. The boiler breaks at 2am. You spend so much time maintaining the house that you never actually enjoy living in it. > In tech: This is a server panel like Forge or Ploi. They set up your server and deploy your app. Everything after that is on you. ### Buy a house, hire a caretaker _Yours AND taken care of_ You buy your own house — full ownership, full control. But you also hire a caretaker who lives nearby and takes care of everything.Leaky roof? Fixed before you notice. Locks outdated? Upgraded overnight. Garden overgrown? Not on their watch. You enjoy your house. They handle the work. > That's strackt. Your servers, fully managed. Your house, our problem. _So what does strackt actually do?_ ## Everything the caretaker does — but for your applications. ### Changes the locks Security updates are applied automatically. When a vulnerability is discovered, strackt patches it — often before you even hear about it. ### Keeps everything up to date Software gets outdated fast. strackt keeps your server's operating system, packages, and configuration current — without you thinking about it. ### Keeps the house in order Servers slowly get messy over time — settings change, files pile up, things break quietly. strackt continuously enforces the correct configuration. No mess. No drift. ### Keeps the blueprints Every configuration is saved as a blueprint. If something goes wrong, strackt can roll back to a previous state in seconds — or rebuild the server from scratch in minutes. ### Puts your app online When you're ready to show the world, strackt takes your code and puts it on your server. Update your app? Just push the new version. strackt handles the rest. ### Watches around the clock A server needs attention 24/7, not just during business hours. strackt watches continuously and acts automatically when something needs fixing. _How it works_ ## Four steps. Then we take over. You don't need to understand servers to use strackt. Here's what happens. ### Step 01: Connect your repo _Show us your application_ Point strackt at your code. It automatically figures out what your app needs — the right software, the right settings, everything. Like a caretaker walking through the house and knowing exactly what to stock. ### Step 02: Your app goes live _Add your server or start on Layover_ Have your own server? Add it and we'll move your app over. Don't have one yet? Your app starts on Layover while you get set up. Like the caretaker setting up a temporary space while your house is being prepared. ### Step 03: Go live _Your app is online_ One click and your app is live on the internet. Update your app? Just push the new version. strackt puts it online without any downtime — your visitors never notice a thing. ### Step ∞: Sleep well _We handle everything from here_ This is where other tools stop. strackt keeps going — security updates, software updates, keeping everything in order. Automatically, continuously. If something goes wrong, we undo it in seconds. _Why this matters_ ## Four things we promise. ### Convenience **You don't lift a finger.** Server maintenance is complicated, tedious, and never-ending. strackt does all of it automatically. You focus on building your product, running your business, or — honestly — just living your life. ### Freedom **Your house, your rules.** Your server. Your choice of hosting company. Your data. Nobody locks you in. If you ever want to leave, everything is yours — no awkward breakup, no data hostage situation. You own it all. ### Cost **Flat-rate. Predictable. No surprises.** Managed platforms charge usage-based pricing that grows when you succeed. With strackt, you pay your hosting company directly — usually a fraction of the cost. Then you pay strackt a flat per-application fee. No tiers, no brackets. No surprises. No bandwidth overages. ### Confidence **We keep the blueprints.** Every change strackt makes is saved as a checkpoint. Something went wrong? Roll back in seconds. Server completely broken? strackt rebuilds it from the blueprint in minutes. Same setup, clean slate. It's like having an undo button for your entire server. _(See the FAQ section under getting-started.)_ > **Your servers. Your applications. Our problem.** — You built your app because you wanted to build something. Not because you wanted to spend your weekends managing servers. That's what we're here for. → [See the technical version](/how-it-works) > > _Early access opens mid-2026. Your first app is on us._ **P.S.** — You might be wondering about the name. **strackt** is a play on *structured stacks* — the tower of technologies that make your app run. We take your stack and give it structure. It also sounds like *strak* — a Dutch word meaning "tight, taut, pulled straight." Disciplined. No slack. We liked that. --- ## How It Works URL: https://strackt.io/how-it-works > Connect a VPS, add a Git repo, push to deploy. strackt detects your stack, provisions NixOS, runs migrations, and applies security patches automatically. No SSH required. ### How it works Connect your repository. Deploy your application. We manage everything underneath — deployment, security, updates, maintenance. Continuously, on your own servers. **You have to choose between experience and ownership.** Managed platforms like Laravel Cloud and Vercel give you a great developer experience — but on their infrastructure, at usage-based prices you can't predict.Server panels like Forge and Ploi give you ownership — but leave maintenance, security, and recovery to you. You're back in the terminal. **Platform experience. Your infrastructure.** strackt manages your applications on your own servers. Connect your repo, deploy your app, and we handle everything after that — continuously, automatically, at a flat rate.You get the developer experience of a managed platform with the economics and ownership of your own VPS. No compromise. _The process_ ## Connect. Deploy. Forget about it. Getting started takes minutes. Staying managed takes zero effort — that's our job. ### Step 01: Connect your repo _Point at your Git repository_ strackt scans your codebase and detects your stack automatically — framework, runtime version, database, cache, queue workers, scheduler. You confirm, we configure. ### Step 02: Your app goes live _Add your VPS or start on Layover_ Have a VPS? Add it as a resource and we'll move your application over with a live migration. Don't have one yet? Start on Layover while you get set up. ### Step 03: Push and deploy _Push code, we deploy_ Push your code and strackt deploys — with environment injection, dependency installation, migrations, and service restarts. Zero-downtime. Automatic. ### Step ∞: We handle the rest _Continuously, automatically_ Security patches applied automatically. Configuration continuously enforced. We tell you when something needs attention. If something goes wrong, roll back in seconds. _The core insight_ ## Configuration drift is structurally impossible. Most tools detect drift after the fact. strackt's infrastructure layer makes drift structurally impossible — your server is defined as code, and that code is the only way state can change. Every update is atomic: it either applies completely or rolls back automatically. _Architecture_ ## Two layers. Each doing one thing perfectly. Infrastructure and application deployment have fundamentally different change frequencies, risk profiles, and rollback needs. strackt treats them as separate concerns. ### Layer 1: Infrastructure: The foundation that never moves OS, packages, networking, services, and security are declared as code. strackt applies this declaration atomically and enforces it continuously. - Operating system and system packages - Web server, PHP-FPM, database, Redis - Firewall rules and system users - Security patches and OS updates _(Changes: Weekly · Rollback: Atomic · Failure: Auto-revert)_ ### Layer 2: Application: Fast deploys on verified ground Application code deploys over SSH onto an infrastructure layer that's already guaranteed correct. Deploys are fast, targeted, and reversible. - Git pull, composer install, npm build - Database migrations - Environment configuration (.env) - Queue workers and scheduler _(Changes: Daily · Rollback: Git-based · Failure: Isolated)_ _Comparison_ ## The best of both worlds. Platforms give you the experience. Server panels give you the ownership. strackt gives you both. | | Server panels | Platforms | strackt | |---|---|---|---| | Infrastructure | Your VPS | Their cloud | Your VPS | | After deployment | You maintain | They maintain | We maintain | | Pricing | Flat-rate | Usage-based | Flat-rate, per-app | | Security patches | Manual | Managed | Automatic, safe | | Config drift | Your problem | N/A | Structurally impossible | | Rollback | Backup restore | Platform-dependent | Seconds, not hours | | Exit strategy | Server keeps running | Migrate everything | Server keeps running | _Under the hood_ ## Built on a stack you can trust. For developers who want to know what's powering the engine. Every choice is here because it's the right one for the job. **Infrastructure — NixOS** Declarative, reproducible, atomic. Every server state is defined as code. The same config always produces the same result. **Secrets — HashiCorp Vault** Short-lived credentials. SSH certificates and application secrets managed centrally, never stored on disk. **Networking — Nebula** Encrypted mesh overlay built at Slack. The control plane reaches your servers over a private network — no public management ports. **Control Plane — Laravel + Filament** The UI, API, and job queue that orchestrates everything. Built on the same stack our customers use. **Realtime — Laravel Reverb** Self-hosted WebSocket server powering live operation logs and deployment progress. No third-party services. > **Your code runs.
You keep building.** — Early access opens mid-2026. Be the first to experience managed applications on your own servers. → [Explain it like I'm five](/what-is-strackt) > > _Early access · Your first app is on us · Cancel anytime_ --- ## Pricing URL: https://strackt.io/pricing > Flat €4 per application per month. Your first application is on us. Bring your own VPS, pay your provider directly. ### Your first app is on us. After that, every app is €4/month. No tiers, no brackets. ### Your first app One app, one server, fully managed. **Free** _No card required_ **Includes:** - Full management - Security patches - Instant rollback - Config enforcement ### Every app after Same rate whether it's app 2 or app 200. **€4** per app per month _Flat rate, no tiers_ **Everything included:** - Unlimited applications - No server limit - No usage-based billing - No bandwidth overages _Why per-application?_ ## You bring the server. We manage your applications. ### You bring the server You pick the provider, region, and specs. Your VPS is a resource you bring — we build on top of it. ### We handle the operations Deployment, security patches, updates, config enforcement, rollback. We handle the operations so you can focus on building. ### Same rate, always No tiers, no brackets, no surprises. Every app costs the same whether it's your second or your hundredth. | Apps | Monthly total | |---|---| | 1 | Free | | 3 | €8 | | 5 | €16 | | 10 | €36 | | 25 | €96 | > Start with one app. See what managed feels like. _Frequently asked questions_ ## Your questions answered. _(See the FAQ section under pricing.)_ --- ## Security URL: https://strackt.io/security > How strackt protects your servers: Vault-managed secrets, automated security patching within 24 hours, signed security.txt, and a clear vulnerability disclosure policy. ### Security at strackt If you've found a vulnerability, we want to hear about it. We take the security of strackt and our customers' infrastructure seriously. If you've found a vulnerability, we want to hear about it. This page describes how to report security issues to us, what we consider in scope, and what you can expect from us in return. ## Reporting a vulnerability Email security@strackt.io. For sensitive reports, please encrypt with our PGP key: Include in your report: - A clear description of the vulnerability - Steps to reproduce, with a working proof of concept - The impact you believe this has - Any suggested remediation, if you have one We do not currently offer monetary rewards. We credit researchers who report valid issues in our hall of fame below, with your permission. We expect to launch a paid bug bounty program after general availability — researchers who report valid issues during this disclosure-only phase will be invited to the private bounty when it opens. ## What you can expect from us - Acknowledgment within 72 hours of your report reaching us. - An initial triage decision within 7 days — whether we consider the issue valid, its severity, and our intended timeline to fix. - Regular updates until the issue is resolved. - Public credit in our hall of fame once the issue is fixed and you've agreed to disclosure. - No legal action against you for good-faith research within the scope and rules below. See "Safe harbor" further down. We aim to fix critical issues within 30 days, high-severity issues within 90 days, and lower-severity issues within 180 days. Complex issues may take longer; we'll tell you if so. ## Scope ### In scope - strackt.io and app.strackt.io - The strackt control plane API - The strackt CLI - The push-to-deploy webhook handler - Authentication, billing, and account management flows - Cross-tenant boundary violations (highest priority — see below) - Vulnerabilities in our control plane that could compromise customer servers we manage ### Out of scope - Customer applications running on strackt-managed servers. These belong to our customers, not us. Report to them. - Direct attacks on customer servers. If you don't operate the server and it isn't a strackt-owned demo server, don't touch it. Attacks reachable through the control plane (e.g., "I made the control plane SSH into a server I don't own") are in scope and welcome. - Third-party services we depend on — Paddle, Bunny, Hetzner, GitHub, HashiCorp, and others. Report directly to them. - Our marketing site CMS, blog, and changelog - Denial-of-service attacks, including volumetric, application-layer, and resource exhaustion - Social engineering of strackt staff, contractors, customers, or vendors - Physical attacks against any infrastructure - Reports from automated scanners without a working proof of concept demonstrating real impact - Missing security headers without a demonstrated attack chain - Best-practice deviations without a concrete vulnerability (e.g., "TLS 1.2 is enabled," "cookie missing SameSite") - Issues requiring a rooted device, a malicious browser extension, or a compromised endpoint - Self-XSS, clickjacking on pages with no sensitive actions, CSRF on logout - Vulnerabilities in software versions older than the current production release - AI-generated reports without a verified, reproducible proof of concept ### Highest-priority categories We pay particular attention to: - Cross-tenant data or control access — any path where one tenant can read, write, or affect another tenant's resources - Compromise of the control plane's ability to act on customer servers — privilege escalation, secret extraction, SSH CA compromise, push-path tampering - Authentication and authorization bypass on the control plane - Secret material exposure — credentials, tokens, keys, especially those with cross-customer reach If you find something in these categories, say so loudly in your report. ## Rules of engagement To stay within safe harbor, please: - Only test against accounts and resources you own - Do not access, modify, or exfiltrate data that does not belong to you — if you accidentally do, stop immediately and tell us - Do not run automated scanners against app.strackt.io without first contacting us - Do not perform denial-of-service testing - Do not use social engineering, phishing, or physical attacks - Give us a reasonable opportunity to fix the issue before public disclosure — we suggest 90 days from initial report, negotiable for complex issues - Do not extort, threaten, or pressure us for payment in exchange for not disclosing — we will not engage with reports framed this way ## Safe harbor If you make a good-faith effort to comply with this policy during your security research, we will: - Consider your research authorized under the Computer Fraud and Abuse Act, the EU NIS2 Directive, the Dutch Computer Crime Act, and equivalent laws in your jurisdiction - Not pursue or support legal action against you - Work with you to understand and resolve the issue quickly If a third party initiates legal action against you for activity conducted in good faith under this policy, we will make it clear that your actions were authorized. This safe harbor applies only to the extent we are legally able to grant it. If you are unsure whether your planned research falls within this policy, contact us at security@strackt.io before testing. ## Coordinated disclosure We follow a 90-day coordinated disclosure timeline by default. We're happy to negotiate this for complex issues that need more time, or to disclose sooner if a fix ships earlier and you'd like to publish. We ask that you do not publicly disclose the issue before we've had a chance to fix it and notify affected customers. ## What we don't do - We don't pay bounties yet. We will, after general availability. - We don't run a public researcher leaderboard with point scores. - We don't NDA researchers. Your report and our response are yours to publish, after coordinated disclosure. --- ## Company URL: https://strackt.io/company > strackt is built solo by Jan-Peter Wiersma. Why one developer is building the managed-hosting platform that managed platforms and DIY both fail to deliver. ### Built by a developer. For developers. strackt exists because managing infrastructure shouldn't be your full-time job. **100+** servers · four years > Same fight every time. Convenience or freedom. Never both. _01_ ## The story I got tired of choosing between convenience and freedom. Over four years, I managed more than 100 production servers. Every one of them presented the same choice: use a managed platform and give up control, or keep your own servers and accept the maintenance burden. Managed platforms are convenient, but they own your infrastructure. Self-hosting gives you freedom, but provisioning tools only handle the setup — everything after that is on you. Security patches, updates, configuration drift. It piles up. I built strackt to eliminate that choice. Your servers, managed like a platform. Full freedom, zero maintenance burden. ![Jan Peter, founder of strackt](/assets/janpeter-portrait.jpg) _JP · April 2026_ _02_ ## The mission Convenience or freedom. Managed platforms or self-hosting. Every developer faces this tension. Managed platforms handle everything but lock you in — their infrastructure, their pricing, their rules. Self-hosting gives you control but leaves you alone with the maintenance. > strackt sits in the space nobody else occupies: fully managed servers that you own. Your VPS, your provider, your data — with continuous maintenance handled automatically. Security patches, configuration enforcement, instant rollback. The convenience of a managed platform without surrendering ownership. That's the mission. Make "your servers, our problem" the default way developers run infrastructure. **i. Freedom** — Any VPS provider. Any region. SSH access. Configuration as code. Leave anytime with your full setup. **ii. Convenience** — Push code, it's live. Security patches applied. Configuration enforced. Continuously, not just at setup. **iii. Confidence** — Every change creates a checkpoint. Roll back in seconds. Rebuild from scratch in minutes. _03_ ## Built in public strackt is a solo founder project. Early access opens mid-2026 — invite-based, small cohort, hands-on onboarding. One person committing to a long arc. The Log is where this gets written down. Wins, mistakes, what I'm stuck on this week. If you want to know what kind of operator I am, that's where to look. See you on the inside. — Jan Peter _(Founder, sole developer)_ > **Want to be part of this?** — Mid-2026 invite-based early access. Small cohort. Hands-on onboarding. → [What to expect](/early-access) --- ## Early Access URL: https://strackt.io/early-access > Early access to strackt opens mid-2026. Invite-only at first. Join the waitlist to be among the first developers running managed servers they actually own. ### Early access opens mid-2026. Invite-based at first. Join the waitlist to be among the first developers running managed servers they actually own. _The plan_ ## You're early. That's the point. The wait between now and mid-2026 is when the work happens — the slow, careful kind that makes day one actually worth showing up for. The waitlist is how you get in line. It's also how you get a say in what we ship. - **Now** — Building. _In public, on The Log._ - **Mid‑2026** — Invite‑based access. _Small cohort. Hands‑on onboarding._ - **Late 2026** — Open access. _Self‑serve onboarding._ - **2027** — GA. _SLAs published. More frameworks._ **Invite preview** — From: Jan Peter, strackt.io; Subject: Your invite to strackt early access > It's your turn. Here's how to connect your first server, and the email I'll be answering when you have questions during onboarding. _Founding cohort_ ## Four things you get for being early. - **i. An invite when early access opens.** — We'll email you when it's your turn. Invites go out in small batches so onboarding stays hands-on. - **ii. A direct line during onboarding.** — Stuck? Email me. Confused by something? Tell me. The first cohort gets my full attention. - **iii. Your feedback shapes v1.** — Founding-cohort input is what turns v1 into something worth using. You'll see your suggestions ship. - **iv. Your first app is on us.** — Free for everyone, founding cohort or not — the standard offer. See pricing. _Honest scope_ ## What v1 does. What it doesn't. We name what we support. No vague promises. **At launch:** - ✅ Connect any VPS — Hetzner, DigitalOcean, Vultr, AWS, Linode. - ✅ Deploy Laravel apps from Git, with stack auto‑detection. - ✅ Apply security patches automatically. Continuously. - ✅ Roll back any change in seconds. Rebuild from blueprint in minutes. - ✅ Flat-rate, per-application pricing. €4/app. First app free. **Not yet:** - ❌ WordPress, Statamic, Next.js — coming after Laravel is solid. - ❌ Multi-region failover — not in v1. - ❌ Custom build steps — opinionated defaults at launch. - ❌ Bring-your-own-Kubernetes — not the audience we're building for. - ❌ SLA commitments — come at GA in 2027. _A note from the founder_ I'm building strackt alone. The way I want to ship it means going slow enough to get things right — safety, reliability, and respect for your infrastructure aren't features I want to bolt on later. The first cohort will be small. Hands-on onboarding. Real conversations. You'll have my full attention while we figure out together what works and what doesn't. > In return: my endless gratitude for your input, your time, your feedback, your wisdom. The people who join early are the people I'll learn the most from — and the platform will be better because of you. — Jan Peter _Before you sign up_ ## Frequently asked. _(See the FAQ section under waitlist.)_ > **Join the waitlist.** — Mid-2026. Invite-based. Small cohort. Your servers. Our problem. → [See how it works](/how-it-works) --- ## Compare strackt URL: https://strackt.io/compare > Side-by-side comparisons of strackt against Laravel Forge, Laravel Cloud, Ploi, and Coolify. We lead with where each competitor wins, name the gaps strackt has openly, and tell you when the other product is the right pick instead. ### How strackt compares Honest, side-by-side comparisons against the products developers actually consider before picking strackt. We lead with where each competitor wins; we say plainly when they're the right pick instead. We're not trying to convert anyone — we're helping you make the right call. --- # Comparisons ## Coolify vs strackt URL: https://strackt.io/compare/coolify-vs-strackt > Coolify is open-source, Docker-native, and self-hostable. strackt is a managed service built on NixOS, deliberately not Docker. Honest comparison of where each fits and when Coolify is the right pick instead. As of April 2026. ### Coolify vs strackt Coolify is Docker. strackt is not. Two different bets about what managed self-hosted should mean. Coolify is a great product. Open-source, Docker-native, with an active community shipping a real platform that thousands of developers self-host on their own servers. We respect what coollabs built. This page isn't a pitch to Coolify users who chose it on principle — they chose right for what they wanted. It's for the developers who came to Coolify looking for managed self-hosted, hit the reality that you still operate the platform and the servers yourselves, and started wondering whether someone else could just handle the substrate while keeping their data on their own VPS. _Where Coolify wins_ ## We start here on purpose. Coolify has real strengths strackt doesn't try to match — and isn't trying to compete with. - Open-source by design. MIT license, free forever for self-hosted, no vendor lock-in. If you want to own the entire stack — including the orchestration platform itself — Coolify is the only one in this comparison that gives you that. We can't and won't. - Docker-native, deeply. Containers, Compose, multi-container stacks, volumes, networking, registries — all first-class. 280+ one-click services. This is what Coolify is built for, and it does it well. - Active community shipping the product. Coolify is open-source, contributable, with a real community on GitHub and Discord. You're adopting an active project, not a side hobby. - Self-host or use the Cloud. Coolify Cloud manages the control plane on a hosted instance from $5/mo for 2 servers (+$3/mo per additional server). The self-hosted version has the same features for free. Genuine flexibility — you can change your mind without changing tools. - Broader application support out of the box. Anything that runs in Docker runs on Coolify — Next.js, Python, Go, Rust, Node, multi-language stacks, anything with a Dockerfile. strackt is Laravel-focused at launch; Coolify covers ground we don't try to. _Where strackt fits_ ## Different bet, deliberately made. A developer who wants managed servers — not an open-source platform to operate. They came to Coolify hoping someone else handled the substrate, and discovered that Coolify hands you the keys to a powerful workshop and a copy of the manual. - Different abstraction layer. strackt configures whole servers declaratively via NixOS. Every package, service, secret, firewall rule expressed as code, applied atomically, with rollback as a first-class operation. Different from Docker's container model — not better, not worse, optimized for a different problem (managing the entire server lifecycle, not just the application surface). - Managed service, not a self-hosted platform. With Coolify you operate the orchestration platform yourself, or pay Coolify Cloud to run the control plane while you still run the servers. With strackt, the management is the product — you don't operate the platform, we do, and we handle the servers underneath too. - Laravel-focused at launch. Narrower, deliberately deeper. Coolify's container-native model lets it support anything with a Dockerfile; strackt is opinionated and that opinion is Laravel for now. If your stack is Laravel, you get the depth. If it isn't, Coolify is genuinely the better fit today. - Long-term server lifecycle is on us. Distribution upgrades (Ubuntu LTS to LTS), fundamental service version upgrades (PHP minor versions, MySQL major versions), the slow-burning maintenance work that piles up over years — strackt does that work continuously across the server, not as Docker image rebuilds you trigger yourself. ## Side by side Numbers as of April 2026; verify on the official Coolify site linked next to every Coolify cell. | | Competitor | strackt | |---|---|---| | Application abstraction | Docker containers | Whole-server declarative (NixOS) | | Platform model | Open-source platform; self-host it or use Coolify Cloud | Managed service — strackt operates everything | | Configuration model | Compose files, Docker primitives, per-service config | Whole-system spec, atomic apply, rollback as a primitive | | Pricing | Free (self-hosted, MIT) / Coolify Cloud from $5/mo for 2 servers (live) | First app free; €4/app/mo after, plus your VPS | | Stack support today | Anything Docker runs (280+ one-click services) | Laravel-focused (more frameworks coming) | | Server access | Full SSH | Full SSH; manual changes get reverted to the spec | | Community model | Open-source, active community, contributable | Solo founder project, no public contributions yet | | Long-term server upgrades | Your responsibility (distro upgrades, major service versions) | Continuous (LTS-to-LTS, PHP minor, MySQL major, etc.) | | Disaster recovery | Container redeploy / Compose replay | Instant rollback (seconds) + blueprint rebuild (minutes) | **Honest read.** Coolify self-hosted is free, full stop — you only pay for the VPS. That's cheaper than strackt at every scale. Coolify Cloud at $5/mo is also cheaper than strackt's per-app rate from app two onward. We're not the cheap option, and we're not trying to be. The strackt price pays for management — patching, configuration enforcement, instant rollback, distribution upgrades — that you absorb yourself with Coolify (whether self-hosted or via Cloud, where Coolify Cloud manages the control plane but not your servers). Different value swap. If you have the bandwidth to operate the platform and want it open-source, Coolify is the right pick. If you'd rather buy back the operating-the-platform hours and you're on Laravel, strackt is what we built for that. _When Coolify is the right pick_ ## We mean this. - You want to own the orchestration platform itself, not just rent management of it. - Docker is your application abstraction — your apps run as containers, you compose multi-container stacks, you depend on Dockerfile-driven workflows. - You're committed to open-source on principle and prefer no vendor relationship at all. - Your team has the bandwidth to operate the platform plus the servers. - You want application breadth (Node, Python, Go, multi-language stacks) that strackt doesn't ship today. Any of those — pick Coolify. We're not trying to change your mind. _When strackt is the right pick_ ## You wanted managed. You found a platform to manage. - You want managed servers, not a platform to manage. - You're on Laravel and you don't need Docker. - Long-term server lifecycle (LTS upgrades, service version upgrades, security patching) should be someone else's job. - You'd rather pay a flat rate per app than absorb the time of operating a platform. - Atomic whole-server rollback is more useful to you than redeploying containers. _(See the FAQ section under compare-coolify.)_ > **Different routes. Pick the one that fits.** — If Coolify is what you want — open-source, Docker-native, self-hosted by you — stay there with our blessing. If you came to Coolify hoping someone else would handle the platform and the servers, and you're on Laravel, strackt is what we built for that. Same provider you'd use for Coolify, new VPS provisioned by strackt, ready to deploy your apps onto. → [What to expect](/early-access) > > _Early access opens mid-2026. Invite-based, small cohort, hands-on onboarding._ --- ## Laravel Cloud vs strackt URL: https://strackt.io/compare/laravel-cloud-vs-strackt > Same push-and-deploy experience as Laravel Cloud, on a VPS you own. Honest comparison: where Laravel Cloud wins, where strackt fits, and the real pricing math. As of April 2026. ### Laravel Cloud vs strackt Same experience. Your infrastructure. Flat-rate pricing. Laravel Cloud is excellent. It's the closest match in the market for the kind of experience strackt builds toward — push your code, it's live, the platform handles the rest. We respect what the Laravel team shipped. The disagreement isn't about experience; it's about who owns the infrastructure and how the bill scales. If their answer fits how you want to run your applications, pick Laravel Cloud. This page is for the developers who love the experience but don't love being locked into someone else's substrate at usage-based prices. _Where Laravel Cloud wins_ ## We start here on purpose. Laravel Cloud has real, specific strengths that strackt doesn't have today. - Global Cloudflare CDN bundled. Laravel Cloud terminates incoming requests at hundreds of Cloudflare edge locations, runs DDoS mitigation and a Web Application Firewall there, and caches static assets near your users — all out of the box. Your application compute still runs in one AWS region you assign (LC has multi-region compute on its 2026 roadmap, not yet shipping). With strackt, you can put Cloudflare in front of your VPS yourself for the same edge layer, but it's not bundled. The bundled edge-plus-WAF is a real LC convenience. - PHP CDN and serverless-edge primitives. Things like Laravel's edge runtime and CDN-aware caching are first-class on Laravel Cloud. We don't have an equivalent today. - Same-team-as-Laravel pedigree. Laravel Cloud ships from the team that builds Laravel. New framework features land with platform-native support. Pulse, Reverb, and Octane tuning are integrated as platform features, not user concerns. - Zero-VPS setup. You don't think about a server, a provider, a region, or a VPS specification. You push and they handle the substrate. For developers who specifically don't want to own a VPS, that's the right answer. - A whole Laravel team behind it. The support channel is the same team that builds the framework. Full team capacity, framework-team backing. strackt is a solo founder project — async ticketing only, smaller capacity. If team-backed support is a hard requirement for your business, Laravel Cloud is the right pick on that axis alone. _Where strackt fits_ ## Same experience. Your infrastructure. A developer running on Laravel Cloud (or Vercel, or Railway). The setup works. They're not unhappy with the experience. But they see the bill, look at what a €4 Hetzner VPS can do, and think: "I could get the same experience for a fraction of this." They don't want to downgrade to a server panel — they want the same push-and-deploy experience, just without the platform tax. - Same push-and-deploy experience. Connect your repository. We detect your stack. Push your code, it's live. Zero-downtime. Automatic. No migration in your workflow. - Your infrastructure, your provider, your data. strackt runs your applications on a VPS you own — Hetzner, DigitalOcean, OVH, anywhere. Your data lives where you put it. Move providers and the configuration travels with you as code. - Flat-rate pricing. First app is on us. Every app after is €4/month. No tiers, no brackets, no usage-based compute or bandwidth surcharges. The bill is the bill. - No usage-based surprises. A traffic spike on Laravel Cloud changes your bill. A traffic spike on strackt does not. - You can always SSH in. The substrate isn't a black box. Full SSH with sudo. strackt enforces the server's specification continuously, so manual changes get reverted on the next configuration cycle — that's the feature, not a limitation. ## Side by side Numbers as of April 2026; verify on the official Laravel Cloud site linked next to every Laravel Cloud cell. | | Competitor | strackt | |---|---|---| | Experience | Platform — push and it works | Platform — push and it works | | Infrastructure | Theirs (AWS-backed, locked in) | Yours (any VPS, any provider) | | Pricing model | Usage-based: compute + bandwidth + storage (live) | Flat-rate: €4/app/mo + your VPS cost | | Bill at scale | Grows with traffic and usage | Fixed — your VPS + your subscription | | Data residency | Their regions | Your choice — pick a VPS anywhere | | Server access | Black box | Full SSH | | Disaster recovery | Platform-dependent | Instant rollback (seconds) + blueprint rebuild (minutes) | | Edge / CDN | Cloudflare CDN bundled — cache + DDoS + WAF at hundreds of edge locations | Bring your own Cloudflare (or any CDN) in front of your VPS | | App compute regions | One AWS region per app today; multi-region planned for 2026 | One VPS per app, in any region you choose to provision | | Framework support | Laravel only | Laravel-focused | | Team behind it | Laravel team — full support capacity, framework-team backing | Solo founder project — async ticketing only, smaller capacity | | Exit strategy | Migrate everything off | Your server keeps running | ## Total cost — what you actually pay each month Hetzner CX22 (€4.50/mo) is the VPS baseline for the strackt column. Laravel Cloud is usage-based — these are reasonable ranges from public reporting; verify your specific case on the live link next to the Pricing row above. As of April 2026. | | Competitor | strackt | |---|---|---| | 1 app (side project) | ~$15–25 | €4.50 (free + VPS) | | 3 apps (small SaaS) | ~$40–80 | €12.50 (€8 + VPS) | | 8 apps (growing) | ~$100–200 | €32.50 (€28 + VPS) | | 20 apps (agency) | ~$300–500 | €80.50 (€76 + VPS) | **Honest read.** strackt is 3–8× cheaper at every scale shown. The reason isn't a discount — it's a different model. Laravel Cloud runs on AWS, charges for compute / bandwidth / storage, and rolls a margin on top. strackt runs on the cheap VPS you already pay for, charges a flat per-app management fee, and that's the whole bill. If your scale is a single high-traffic application where AWS edge economics genuinely win, the math can flip. For most Laravel applications below that ceiling, the gap is large and consistent. _When Laravel Cloud is the right pick_ ## We mean this. - You want the substrate handled. You don't want to think about a VPS, a provider, or a region. - Your audience is global and edge-runtime / multi-region matters more than predictable pricing. - You want first-party Laravel-team integration and support. - Your scale or shape (one massive app, lots of bursty traffic) makes per-VPS economics impractical. - You explicitly want a managed cloud with vendor responsibility for the substrate. Any of those — pick Laravel Cloud. We're not trying to change your mind. _When strackt is the right pick_ ## You love the experience. You don't love the bill. - You love the platform experience but don't love the usage-based bill. - You want to own your VPS, your provider, your data residency. - Predictable monthly cost matters more than multi-region edge. - A traffic spike shouldn't reshape your invoice. - You'd happily run a €4 Hetzner box if someone else managed it for you. _(See the FAQ section under compare-laravel-cloud.)_ > **Same experience. Your infrastructure. Flat bill.** — If Laravel Cloud is what you want and the bill works for you, stay. If you've been doing the math on your own VPS but couldn't bring yourself to downgrade to a server panel, strackt is the path you've been looking for. Same push-and-deploy. A VPS at the provider you choose, provisioned by strackt and owned by you. Your data. Flat €4 per app. → [What to expect](/early-access) > > _Early access opens mid-2026. Invite-based, small cohort, hands-on onboarding._ --- ## Laravel Forge vs strackt URL: https://strackt.io/compare/laravel-forge-vs-strackt > Laravel Forge provisions your server. strackt manages it continuously. Honest comparison of pricing, scope, and where Forge is the right pick instead. As of April 2026. ### Laravel Forge vs strackt Laravel Forge provisions your server. strackt manages it. Forge is the canonical Laravel server panel. It's mature, battle-tested, and the right answer for thousands of developers. We're not trying to change that. If you want to set up a server and run it yourself, Forge is what you should pick. This page is for the developers who started with Forge, hit the maintenance treadmill, and started wondering whether someone else could just handle it. _Where Laravel Forge wins_ ## We start here on purpose. If we can't be honest about what Forge does better, you shouldn't trust the rest of the page. - Mature and battle-tested. Forge has been running production Laravel servers since 2014. The edge cases are caught. The integrations are deep. There is a Stack Overflow answer for every question. - Larger community. The Laravel community lives on Forge. Almost every Laravel developer has used it or knows someone who runs everything on it. - Cheaper from app 2 onward. Forge's flat-tier model means a $12/mo Hobby subscription covers unlimited apps on a single server. Past your first app, Forge is cheaper than strackt's per-app €4 rate. If raw cost is your primary axis, Forge wins almost everywhere — see the Total cost table below for the real numbers. - Broader stack support today. Forge handles PHP frameworks beyond Laravel, plus Node and static sites. strackt is Laravel-focused at launch — that gap closes over time, but it is real today. - A whole Laravel team behind it. Forge ships from Taylor Otwell's team — first-party Laravel integration and a full team's support capacity. strackt is a solo founder project; we say so on the company page, and we say so here. If team-backed support matters to your team, that gap is real and you should weigh it. _Where strackt fits_ ## Forge sets up. strackt manages. A dev lead at a 5–10 person company, running on Forge today. The setup works. They're not in crisis. But they're tired of the maintenance treadmill — the patches, the OS upgrades, the "did this server drift?" anxiety. They want to stop thinking about servers and start thinking about product. - Forge sets up. strackt manages. Forge provisions your server and deploys your app. After that, every patch, every OS update, every configuration drift, every recovery is on you. strackt manages the server continuously — security patches applied automatically, configuration enforced declaratively, recovery as a one-click action. - Configuration drift goes away. Your strackt server always matches its specification. If something has been changed manually, the next configuration cycle reverts it — or surfaces it for your review. There's no "what's actually running on this box?" anymore. - Disaster recovery shrinks from hours to seconds. On Forge, restoring from a broken state usually means a backup restore — minutes if you're lucky, hours if you're not. On strackt, every change creates a checkpoint. Roll back in seconds. Or rebuild from blueprint in minutes — same configuration, clean slate. - App-centric, not server-centric. On Forge you open a server to see what is on it. On strackt you open an application to see it running, and the server is a resource we placed it on. Different protagonist. Better for developers who think in apps, not in machines. ## Side by side Numbers as of April 2026; verify on the official sites linked next to every Laravel Forge cell. | | Competitor | strackt | |---|---|---| | Primary object | Server — open it to see what is on it | Application — open it to see it running | | What it does | Provisions and deploys | Provisions, deploys, and manages continuously | | After deployment | You maintain | strackt maintains | | Configuration drift | Your problem | Enforced — server always matches its specification | | Security updates | Manual or scheduled, your responsibility | Automatic, applied within 24 hours | | Disaster recovery | Backup restore (hours) | Instant rollback (seconds) + rebuild (minutes) | | Stack detection | Manual selection | Automatic from your Git repository | | Pricing | $12–39/mo flat (live) | First app free; €4/app/mo after, plus your VPS | | Stack support today | PHP / Laravel / Node / static | Laravel-focused (more frameworks coming) | | Team behind it | Taylor Otwell's Laravel team — full support capacity, first-party framework backing | Solo founder project — async ticketing support only, smaller capacity | ## Total cost — what you actually pay each month Hetzner CX22 (€4.50/mo) is the VPS baseline for both columns. Forge tier names verified on forge.laravel.com/pricing as of April 2026. USD-to-EUR conversion approximate. | | Competitor | strackt | |---|---|---| | 1 app (side project) | ~€15.50 (Forge Hobby $12 + €4.50 VPS) | €4.50 (free + VPS) | | 3 apps (small SaaS) | ~€15.50 (Forge Hobby covers unlimited sites on 1 server) | €12.50 (€8 + VPS) | | 8 apps (growing) | ~€22 (Forge Growth $19 + €4.50 VPS — unlimited servers) | €32.50 (€28 + VPS) | | 20 apps (agency) | ~€40.50 (Forge Business $39 + €4.50 VPS — adds priority support) | €80.50 (€76 + VPS) | **Honest read.** Forge wins on raw price at every scale shown except the very first app (where strackt's free first app makes us the cheap option). Forge's tier model — flat per-account fee, unlimited sites — is genuinely cheaper than strackt's per-app €4 from app 2 onward. We're not the cheap option. The strackt price isn't a discount — it's a different model that includes continuous management Forge doesn't (automatic patching, configuration enforcement, instant rollback, distribution upgrades, fundamental service version upgrades). If your team has the bandwidth for ongoing maintenance and budget is the primary axis, Forge is the right pick. If you'd rather buy back the hours your team would spend reconciling servers, strackt's higher per-app price is paying for the management, not for cheaper hosting. _When Laravel Forge is the right pick_ ## We mean this. - You want full control of the server day to day, and you enjoy that work. - Cost matters more than continuous management — Forge's flat-tier model is cheaper than strackt's per-app rate from app 2 onward. - You need framework / stack support strackt does not ship today (non-Laravel PHP frameworks, Node-only services, static-only deployments). - You're already on Forge, the setup works, and you don't want to migrate. Any of those — pick Forge. We're not trying to change your mind. _When strackt is the right pick_ ## You started with Forge. The maintenance is starting to add up. - You started with Forge, the maintenance is eating into product time, and you're looking for the next step. - You want someone else to handle patches, drift, and recovery — without giving up your VPS or your provider relationship. - Configuration enforcement matters: your servers should always match their specification. - A €4-VPS-plus-flat-rate-management bill is more predictable than a usage-based platform. - You'd rather ship features than reconcile infrastructure. _(See the FAQ section under compare-forge.)_ > **Your Laravel apps. Less of your time.** — If Forge has gotten you this far and the maintenance is starting to add up, strackt is the next step. Same provider, same SSH access — but a new VPS, provisioned by strackt and ready for us to deploy your existing applications onto. You keep your provider relationship; we take care of everything that comes next. → [What to expect](/early-access) > > _Early access opens mid-2026. Invite-based, small cohort, hands-on onboarding._ --- ## Ploi vs strackt URL: https://strackt.io/compare/ploi-vs-strackt > Ploi is a fine server panel — flat-tier pricing, broader stack support, server monitoring on Pro tier and above. strackt manages your server continuously so you're not stuck on the maintenance treadmill. Honest comparison of pricing, scope, and where Ploi is the right pick instead. As of April 2026. ### Ploi vs strackt Ploi provisions your server. strackt manages it. Ploi is a fine server panel. Mature, multi-stack, with built-in monitoring that goes deeper than most of the category. We're not trying to win Ploi users who are happy with their setup. This page is for the developers who started with Ploi, hit the maintenance treadmill, and started wondering whether someone else could just handle it. _Where Ploi wins_ ## We start here on purpose. Ploi has real strengths strackt doesn't try to match. - Stronger built-in monitoring on paid tiers. On Ploi's Pro tier (€13/mo) and above, you get real-time server monitoring — CPU, memory, disk, network, with threshold alerts — plus Server Insights, an automated configuration analyzer that flags issues and offers one-click fixes. The Unlimited tier (€30/mo) adds uptime monitoring across daily, weekly, and monthly windows. strackt's monitoring is lighter today; we plan proactive alerts with developer-language framing, but Ploi's existing monitoring depth on its higher tiers is a real strength right now. - Broader stack support today. PHP, Laravel, Node, and static deploys, plus a Docker-server option. strackt is Laravel-focused at launch — if you need Node or static-only workflows today, Ploi covers more ground. (See the Docker FAQ below for an honest read on what each side actually does with containers.) - Mature, loyal community. Smaller than Forge's, but Ploi users tend to be Ploi loyalists. The product has been polished over years against real customer feedback. - Flat-rate at every scale. Per-server panel pricing. Past around 20 applications on a server, the per-app math flips in Ploi's favor — same shape as the Forge comparison. - An actual team behind it. Ploi ships from a small but real team. strackt is a solo founder project — async ticketing only, smaller capacity. Smaller gap than Forge or Laravel Cloud, but it exists. If team-backed support matters to you, Ploi has more of it than we do. _Where strackt fits_ ## Ploi sets up. strackt manages. A dev lead at a 5–10 person company, running on Ploi today. The setup works. They're not in crisis. But they're tired of the maintenance treadmill — the patches, the OS upgrades, the "did this server drift?" anxiety. They want to stop thinking about servers and start thinking about product. - Ploi sets up. strackt manages. Ploi provisions your server, deploys your app, and gives you good monitoring. After that, every patch, every OS update, every configuration drift, every recovery is on you. strackt manages the server continuously — security patches applied automatically, configuration enforced declaratively, recovery as a one-click action. - Configuration drift goes away. Your strackt server always matches its specification. If something has been changed manually, the next configuration cycle reverts it — or surfaces it for your review. Ploi shows you what's happening; strackt enforces what should be happening. - Disaster recovery shrinks from hours to seconds. On Ploi, recovering a broken server usually means a backup restore. On strackt, every change creates a checkpoint. Roll back in seconds. Or rebuild from blueprint in minutes — same configuration, clean slate. - Long-term work is on us. Distribution upgrades (Ubuntu LTS to LTS), fundamental service upgrades (PHP minor versions, MySQL major versions), and the slow-burning maintenance that piles up over years — strackt does that work continuously so you never inherit a five-year-old box you're afraid to upgrade. - Opinionated depth, not feature breadth. strackt won't add a thin Docker option to chase a feature checkmark. We chose NixOS deliberately and we go deep — declarative configuration, distribution upgrades, atomic rollback. The trade-off: narrower stack support today. We'd rather do fewer things well than many things shallowly. ## Side by side Numbers as of April 2026; verify on the official Ploi site linked next to every Ploi cell. | | Competitor | strackt | |---|---|---| | Primary object | Server — open it to see what is on it | Application — open it to see it running | | What it does | Provisions, deploys, monitors | Provisions, deploys, and manages continuously | | After deployment | You maintain | strackt maintains | | Configuration drift | Your problem (visible in monitoring) | Enforced — server always matches its specification | | Security updates | Manual or scheduled, your responsibility | Automatic, applied within 24 hours | | Long-term maintenance | Your responsibility (distro upgrades, major service versions) | Continuous (LTS-to-LTS, PHP minor, MySQL major, etc.) | | Disaster recovery | Backup restore (hours) | Instant rollback (seconds) + rebuild (minutes) | | Built-in monitoring | Server monitoring on Pro (€13/mo) and above; uptime monitoring on Unlimited (€30/mo) | Lighter today; proactive alerts on the roadmap | | Stack support today | PHP / Laravel / Node / static, plus a basic Docker-server option | Laravel-focused — deliberate depth over breadth | | Pricing | Free (1 app, 1 server) / Basic €8 / Pro €13 / Unlimited €30 — all flat-rate per account, plus your VPS (live) | First app free; €4/app/mo after, plus your VPS | | Team behind it | Small but real team — broader support capacity | Solo founder project — async ticketing only, smaller capacity | ## Total cost — what you actually pay each month Hetzner CX22 (€4.50/mo) is the VPS baseline for both columns. Ploi tier names verified on ploi.io/pricing as of April 2026; verify your specific case on the live link next to the Pricing row above. | | Competitor | strackt | |---|---|---| | 1 app (side project) | €4.50 (Ploi Free + €4.50 VPS) | €4.50 (free + VPS) | | 3 apps (small SaaS) | ~€12.50 (Ploi Basic €8 + €4.50 VPS) | €12.50 (€8 + VPS) | | 8 apps (growing) | ~€17.50 (Ploi Pro €13 + €4.50 VPS — adds server monitoring) | €32.50 (€28 + VPS) | | 20 apps (agency) | ~€34.50 (Ploi Unlimited €30 + €4.50 VPS — adds uptime monitoring + team) | €80.50 (€76 + VPS) | **Honest read.** Ploi's flat-tier model means it's cheaper than strackt on raw price at every scenario shown — even Ploi's free tier covers a single app on a single server. strackt's per-app €4 adds up faster than Ploi's per-account flat rate. We're not the cheap option. The strackt price includes continuous management Ploi doesn't (automatic patching, configuration enforcement, instant rollback, distribution upgrades). If your team has the bandwidth for ongoing maintenance and you can absorb upgrade work in-house, Ploi is genuinely cheaper. If you'd rather buy back the hours your team would otherwise spend reconciling servers, strackt's higher per-app price is paying for the management, not for cheaper hosting. _When Ploi is the right pick_ ## We mean this. - You want full control of the server day to day, and you enjoy that work. - You're running mixed stacks today — PHP, Node, or static-only deploys — that strackt doesn't support yet. - Built-in monitoring depth is a non-negotiable feature for your team. - You're past 5–8 applications and the per-app math favors Ploi's flat tiers. Any of those — pick Ploi. We're not trying to change your mind. _When strackt is the right pick_ ## You started with Ploi. The maintenance is starting to add up. - You started with Ploi, the maintenance is eating into product time, and you're looking for the next step. - You want someone else to handle patches, drift, recovery, and long-term distribution upgrades — without giving up your VPS or your provider relationship. - Configuration enforcement matters: your servers should always match their specification. - You'd rather ship features than reconcile infrastructure. - You don't need Docker, and you're happy on Laravel + a couple of services. _(See the FAQ section under compare-ploi.)_ > **Your Laravel apps. Less of your time.** — If Ploi has gotten you this far and the maintenance is starting to add up, strackt is the next step. Same provider, same SSH access — but a new VPS, provisioned by strackt and ready for us to deploy your existing applications onto. You keep your provider relationship; we take care of everything that comes next. → [What to expect](/early-access) > > _Early access opens mid-2026. Invite-based, small cohort, hands-on onboarding._ --- # The Log ## Month 63 URL: https://strackt.io/blog/month-63 Published: 2026-05-09 Author: Jan Peter Wiersma > Month 63 of building strackt. April was a refactor month — 169 issues, 400 commits, an architectural correction 18 months in the making. The kind of progress that doesn't feel like progress until you look back at it. April was a refactor month. Those are hard to feel good about; the numbers are big and the visible progress is small. That's fine — it's what needed to happen — but it's worth being honest about what it actually felt like. What Moved ---------- Until now, an application and its running environment were the same thing. One app, one set of secrets, one set of domains, one deploy target. That works fine as long as it's a simple project; it stops working the moment you want staging next to production, or automatic environments for every pull request, or a clean way to clone a deployment. Those are the features that make a managed platform useful for applications instead of static websites — and none of them were possible with the old model. April changed that. Applications now hold source identity; environments own everything that runs. Secrets, domains, scheduler, queue workers — all scoped per environment, so production and staging can't step on each other. The architecture is now shaped the way the product needs to be. This is a correction. The split should have been there from the start; it wasn't, and that's on me. What surprised me is how fast it went — four weeks to untangle eighteen months of the wrong model, 169 issues closed, everything staying stable while it happened. That's worth something. What Didn't ----------- The feeling of a straight line forward. A refactor at this scale absorbs everything around it — even when firewall management ships, the CLI gets SSH access, reboot detection lands, secrets move per-environment — it all gets pulled into the gravity of the big structural change. You're not just building; you're building while correcting the foundation underneath. It's not gloomy, it's just not the same as gliding. Would I Pay For This Today? --------------------------- Yes — and I'm running it. strackt manages this website, the tooling, the development environments. Through four weeks of architectural refactoring, servers kept running, deploys kept working, nothing went offline. That's the proof I care about most; not a demo, not a pitch — just uptime through the messy part. The asterisk: what exists today is still too complex. As I wrote last week, what we're adding now needs to be removed later. The multi-environment work unlocks the right features; the new UI layer running in parallel is what will make them feel right. We're not there yet. But I'd pay for the stability while we get there. Next Month ---------- Testing. The multi-environment split is in; now it needs to be proven. Running it, breaking it, finding the edges. Once the obvious issues are out of the way, the interesting features unlock: automatic PR environments, environment cloning, the things that make the architecture worth having. That's what May is for. Four weeks to fix a decision from eighteen months ago; let's see what we can do with the next four. --- ## Adding UI to remove UI URL: https://strackt.io/blog/adding-ui-to-remove-ui Published: 2026-05-05 Author: Jan Peter Wiersma > We're adding UI now so we can take it away later. Most server platforms grow knobs forever; most clouds hide everything. We're picking neither. The UI isn't there because we plan to keep it. It's there because we need it to find out what to keep. We're the first user. Every button, every panel, every debug log on screen is something we're triggering ourselves — testing what fires when, watching what breaks, figuring out which moments need a notification and which ones can stay quiet. > The interface is research. The loop is pretty simple: add functionality with a button next to it; watch how it ties into the rest; see what we end up triggering most, checking most, looking at most. Then peel away the buttons we never use. Remove the option. Automate the behaviour. The end state is fewer buttons every quarter. Which means the server panel — the most cluttered surface in strackt right now — is the one we expect to shrink the most. Today the server panel is dense — every screen pulling you in to look at something and decide something. That's not where it lands. The server view we're building toward asks four questions: is it being used efficiently, is it performing the way it should, how are the maintenance levels, and should you bring another one on board. That's it. Beyond that, a visual overview of what your server actually is — its capacity, its workloads, what's running on it — and almost no buttons. Because the truth is: we don't actually need you to configure your server. We need you to bring it. Compute capacity, storage capacity, a place for us to run things. The rest is our problem. You'll still see your server. You'll still be able to take it back and run it yourself if you change your mind — that's never going away. But while strackt is managing it, you shouldn't have to think about it as a server. You know it's there; you don't have to touch it. --- Look at how the rest of the industry handles this and you find two answers — both of them positions, both of them extreme. Server control panels have spent the last decade adding. Forge, Ploi, RunCloud — every release is more graphs, more fields, more switches, more firewall rules to configure, more deploy hooks to wire up. The thesis is control: hand the developer every knob and trust them to know which to turn. The interface keeps growing because every release adds choices and never removes them. Managed clouds went the other way. Heroku, Render, Fly, Laravel Cloud — you push, it runs, and you never see how. A deploy log, a metrics graph, a billing page. That's the surface. The thesis is opacity: hand the developer nothing and charge them for the privilege of not having to think. You don't worry about how because you can't. Both took a position. Neither direction is the one we chose. --- strackt sits in the middle. You bring your own resources — your own VPS, your own provider, your own bill. We do the work to keep them running well. You don't have to think about how, but you can see what we're doing whenever you want, and you can walk away with your server in working order whenever you want. That position is harder than either extreme. The control panel route is easy: build a UI, ship it, leave the user to figure it out. The cloud route is also easy in its own way: hide the machine, charge a margin on the abstraction, never explain. The middle requires us to make decisions for you that work, and to keep making them as the world changes — without burying you in the proof or pretending the work doesn't exist. The hardest product work is the discipline to remove. To resist the pull of more graphs, more switches, more configs; to look at what we built last quarter and decide which parts you shouldn't have to see anymore. That's the work of an opinionated platform: figuring out what you actually need, then doing it for you before you need it. So expect strackt to keep growing for now. New panels, new controls, new ways to see what's happening on your server. The work behind it is what comes after: figuring out what you don't need to see, and removing it. That's the part most platforms never get to. We plan to. --- ## The Work You'll Never See URL: https://strackt.io/blog/work-youll-never-see Published: 2026-04-17 Author: Jan Peter Wiersma > Two weeks, no hero features. The boring reconfiguration work that keeps your server steady — and why most of what strackt does, you'll never see. Two weeks of work. No hero features. No launch post, no feature banner, no "we're thrilled to announce." And yet — loads of stuff shipped. This is what fully managed actually looks like under the hood. Start with what you'll see. The firewall's been there since day one, but only as infrastructure — hardcoded, iptables-based, secure but untouchable; the kind of "put something sensible in place and fix it later" decision you make early and live with. This sprint, the fix landed. New nftables-based implementation, aware of what each service exposes, with sensible defaults so you don't have to choose, and a UI on top for when you want control. The part we're opinionated about: because strackt servers live on Nebula, you don't actually need SSH exposed to the public internet. If you still want it open — fair, you want to be able to log in without a VPN — you can now lock port 22 to a source allowlist. SSH only from your laptop's IP; closed to everyone else. Inside the app itself, the service picker, the source picker, the connect modal grew up in parallel, each solving the same problem in slightly different shapes. This sprint we aligned them: one picker across confirm, edit, and connect. The visible change is a smoother experience; the underlying change is that we took away a lot of exceptions and standardised what's actually happening. --- Underneath the UI, the quiet work: live service configuration — database users, credentials, settings — now runs over SSH, fast and direct, while the actual provisioning stays on NixOS where it belongs; service connections went TCP-only, which sounds small but is what makes migrations between servers clean instead of requiring a re-provision; server names got consistent across the app, so the name you see in the dashboard matches the name you'd type in your terminal; and we pinned databases to one running version of MariaDB's LTS line — no MySQL option, no version sprawl, one opinionated choice. These are the building blocks of keeping a system like strackt steady. This is the boring reconfiguration work we do so you don't have to — the LTS upgrades you don't need to track, the server names you don't need to reconcile, the connection model you don't need to maintain. The kind of work that would otherwise pull you out of your code. That's the gap we close, with two weeks like this one. The majority of what strackt does, you'll never see — and when you come back to your server, this is the work that keeps it smooth. --- ## The Invisible Backbone URL: https://strackt.io/blog/the-invisible-backbone Published: 2026-04-03 Author: Jan Peter Wiersma > We built a secure overlay network to manage your servers without a single open port. Then it became a cross-provider VPC. The only way to manage someone else's machine is if you can protect it. But to actually run a VPS — provisioning, deployment, updates, monitoring — you need full access. Those two things are in tension; you can't have both over a public network. Going in through the front door means open ports, exposed SSH, firewall rules you hope the customer hasn't changed. That's not management; that's hoping for the best. So you build an overlay network. One that connects your control plane to every managed machine without touching the public internet. For what strackt does, it's not optional — it's a necessity. Why Nebula ---------- We were using Tailscale before this. Tailscale is a great product — really good at building networks where you invite people, collaborate with a team, coordinate access through a dashboard. But it's designed around that model; it's not built for a central control plane orchestrating hundreds or thousands of nodes. And cost-wise, that scales in the wrong direction for us. Nebula is different. It was built at Slack for exactly this use case — a large number of nodes, centrally orchestrated. It's open source, now maintained by Defined Networking, and built on the Noise protocol framework (the same cryptographic foundation as WireGuard, but an independent implementation). Simple infrastructure, extremely robust. Every node gets a signed certificate that defines who it is and who it can talk to. Groups, firewall rules, access — all baked into the cert itself. No central authority needs to be online for two nodes to authenticate each other; they just verify each other's signatures. The thing that makes this a pretty natural fit is that strackt is already a provisioning tool. Certificate access and key rotation on those machines? Just part of the normal lifecycle. It's not extra work; it's the work we were already doing. What this means for your server ------------------------------- When you connect a server to strackt, it joins the overlay automatically. We configure it, keep the certificates rotated, keep it secure. You don't interact with any of this. All traffic between your server and our control plane goes through the overlay. Your machine is reachable by us and invisible to everything else. You can close every public port, including SSH. The attack surface drops to pretty much nothing. For now, this is the foundation that makes strackt's operational model possible. But it's also what future features build on — load balancing across servers, dedicated database servers, multi-server deployments. We're not building throwaway plumbing; this is the backbone. Cross-provider VPC ------------------ This started as infrastructure we needed for ourselves. But the same network that connects your servers to our control plane can also connect your servers to each other. Enable it, and we reconfigure the certificates so your machines are allowed to communicate over the overlay. That's it. Your server at Hetzner can reach your server at DigitalOcean on a private address, peer-to-peer. They don't need to be at the same provider, in the same datacenter, or on the same network. They just talk. The obvious use case: database on one server, application on the other. Point your app at the overlay IP, and the connection is encrypted end-to-end. No public database ports, no firewall juggling, no provider-specific VPC that locks you into one platform. Two birds, one stone. --- We built this because we had to. You can't reach servers securely over the public internet. So we built the plumbing. Turns out that plumbing is pretty useful for everyone. Cross-provider VPC, private addresses, encrypted connections between your machines — all from infrastructure that was already there. The best features are the ones that fall out of good architecture. --- ## Month 62 URL: https://strackt.io/blog/month-62 Published: 2026-04-03 Author: Jan Peter Wiersma > Month 62 of building strackt. The pieces are connecting, the foundational infrastructure is starting to work like a platform, and for the first time the work is giving energy back. The confidence is new. Not the idea — that's been there for years — but the feeling that this might actually work. Something shifted over the last couple of months; the pieces are connecting, and instead of draining me, the work is giving energy back. What Moved ---------- March was the month things went public. Not just a project website — strackt.io now has real promises on it. What the platform will do, what it'll cost, who it's for. That changes things; it's not a side project anymore when there's a page telling people what to expect. Under the hood, the foundational pieces are landing. Application mobility, rollbacks, ZFS snapshots, per-app isolation — the stuff that makes "managed platform on your own infrastructure" more than a tagline. It's starting to actually work that way. And the shift I notice most: I'm not fighting the basics every day anymore. The days are moving toward UI, UX, tone of voice, visuals. The experience layer. That's new. We also shipped Nebula — a mesh overlay network that gives every server a built-in VPC across providers. Your Hetzner box and your DigitalOcean box talk to each other privately, out of the box. Pretty cool for something that's just... there. What Didn't ----------- The balance is still tricky. I want to spend more time on strackt, but I also want to be present in the evenings and weekends. There's no clean line between the two; I just notice when I've been on one side too long. And the thing I keep avoiding: showing it to people. Not the website — that's public now, fine. But actually asking someone to look at what I've built, use it, tell me what they think. It's incredibly difficult to step out and invite judgement on something you've been building alone for years. I know it's necessary. I'm not there yet. Would I Pay For This Today? --------------------------- No. But it's piquing my interest. If strackt can deliver on what's there, the experience will be noticeably smoother than what I'm used to. It's not there yet — but for the first time it feels like it could get there. Next Month ---------- April is about proving the basics hold up. Running things, watching them, seeing how the processes behave over time instead of just the moment they ship. Beyond that: monitoring and visibility built into the platform, proper dev/preview/production environments, deployment and backup processes. And keep pushing on the foundational features that are going to deliver this experience. It's spring; things are blooming. --- ## Company of One URL: https://strackt.io/blog/company-of-one Published: 2026-03-25 Author: Jan Peter Wiersma > Paul Jarvis's Company of One didn't give me a plan. It gave me the conviction to try — and two principles I've been building around ever since: focus on the user; automate me. A two-minute deploy that takes two hours isn't a deployment problem. It's a maintenance problem. The server hasn't been touched in months; the dependency chain is out of date, the distribution updates haven't run, and by the time you've untangled it all, you've lost the evening. Every change needs to run on every server — and there's always something you forget. They're never quite in sync. So whenever you need to make a change, you're not just deploying; you're catching up first. It's also never the right moment. Server maintenance doesn't get planned. It finds you. I was running this across my own servers and client servers at the time. Ubuntu 16.04 running PHP 7.0, no way to run a current Laravel without a full OS upgrade — which breaks something, which needs debugging, which costs the time you didn't have. Pretty standard. Pretty much every server I've ever touched. Building a tool for yourself is easy. Building a product for others means you have to actually finish it. strackt started as an itch. I was tired of the maintenance loop — so I started building something that fixed it for me. That was enough for a while. But at some point the question shifted: do I keep this as a personal tool, or do I build it into something real? Turning it into a product meant different standards. It couldn't just fix my problem; it had to fix it well, reliably, for someone who wasn't me — at a moment when I wasn't there to help. I wasn't sure I had the resources to pull that off alone. --- Reading Company of One by Paul Jarvis didn't give me a plan. Company of One isn't really a business book — it's a reframe. Paul Jarvis's argument is that staying small isn't a failure to grow; it's a deliberate strategy. That growth for its own sake is a trap. That a business built carefully, without investors or headcount, can be more resilient than one that scales before it's ready. It covers a lot: how you run a company, how it fits into your life, what you actually need versus what you assume you need. I read all of it with strackt in my head — not looking for a blueprint, more looking for reasons it could work. It gave me enough. I decided to at least try building it properly. Didn't know if I'd finish it. But if I did, it would need to be able to run without me. > I took two things from it: focus on the user; automate me — both ended up baked into strackt at the foundation. "Focus on the user" means the product isn't built from my perspective — it's built from yours. No technical jargon. No configuration screens that require you to already know what you're configuring. Simple wizards, progressive disclosure, the server doing what it's supposed to do without you needing to understand how. You shouldn't have to think about what's happening underneath; you should just see that it works. "Automate me" is how I think about my own work in general: how do I make myself redundant? For strackt, that means automatic updates, automatic patching, automated management. The product handles the maintenance loop so that nobody — not you, and not me — ever has to. If you run into a problem and solve it without ever contacting support, that's the win. --- The book convinced me it was possible. It didn't tell me how to be good at things I'm not good at. I'm a developer. I know what good looks like — a clean interface, a well-placed tooltip, a workflow that just makes sense. I know what doesn't work. What I don't always know is how to make it. Design, visuals, the creativity side of building a product — not my strengths. And as a company of one, there's nobody to hand that off to. I had the conviction. I had the technical foundation. I sat with that gap for a while. The company-of-one model always made sense. What changed is that the tools caught up. AI handles the parts I'm not good at — design direction, visuals, the creative gaps — well enough that I can move forward without a team. Not perfectly; there's always a moment where you can tell it didn't quite get it. But without it, there's no product. It's the same logic as strackt. You like developing; you don't like managing servers. strackt covers that gap. I like building; I just can't design. AI covers mine. The conviction was always there. Now so are the tools. --- # Authors ## Jan Peter Wiersma URL: https://strackt.io/authors/jan-peter-wiersma Role: Founder · solo developer > Founder of strackt. Over a decade managing production servers. Built strackt to remove the trade-off between managed convenience and self-hosting freedom. Jan Peter has been managing production servers for over a decade — more than 100 across four years on his current count. He started strackt after watching the same trade-off play out every time: pick a managed platform and give up your infrastructure, or self-host and accept the maintenance burden. strackt is the answer he wanted to exist. Fully managed servers on infrastructure you own. The convenience of a managed platform, with none of the lock-in. ---