Core
ServersProvisioning in 5 minutes SitesWordPress, Laravel, PHP DeployOn push, with no downtime DatabasesMySQL, users, privileges DockerContainers alongside your sitesAI and automation
AI assistantManage your server in plain words MCP server80 tools for Claude and Cursor Operations centerEvery task step with logs Auto-tuningSettings tuned to your hardwareObservability
MonitoringMetrics, APM and alerts LogsNginx, PHP, MySQL, application BackupsTo your storage, encrypted ClustersServers and sites togetherSecurity and access
SecurityFirewall, Fail2Ban, isolation NetworkingInterfaces, DNS, diagnostics Web terminalCommands without an SSH client ConfigurationPHP, Nginx, MySQL from the panelManage servers from Claude and Cursor
Who it's for
WordPress2-click install, WP-CLI LaravelQueues, Horizon, Reverb For web agenciesAll clients in one panel For freelancersClient servers in one placeComparisons
Deploykin vs Laravel Forge Deploykin vs Ploi Deploykin vs RunCloud Deploykin vs ISPmanagerA running server connects as it is: the panel scans its packages, sites and databases. There is a separate wizard for Ploi.
How to connect a running serverA developer pushes code — the site updates automatically. No SSH, no manual steps, no downtime.
Visitorsapp.example.com
git clone --depth 1
2 s
composer install
11 s
npm run build
19 s
artisan migrate
3 s
releases/20260930183012
releases/20261001140211
How it works
You connect the repository once. After that every push to the selected branch takes the same path — from the webhook to the release switch.
OAuth authorization, deploy key (read-only) and webhook are created automatically.
Any push to the selected branch triggers a deploy. Or accumulate changes with delayed deploy.
The release is built in its own directory and current is switched atomically. If the build fails, the site stays on the previous version.
A project without Git is deployed from an archive — into the same releases directory and with the same current switch.
Deploy control
Auto-deploy, a delay, your own script, history with rollback and a live log — no SSH and no home-grown pipelines.
OAuth authorization, a read-only deploy key and a webhook — everything is set up automatically. Just pick a repository and a branch.
Don't want to rebuild the site on every push? Set a delay: pushes that arrive in a row are batched into one deploy, and the panel shows a timer and the commit that will go out.
Tailor the deploy script to your project. By default — a ready-made script for Laravel: pull, install, build, migrations, cache.
Full history: commit, author, status, run time and logs for every deploy. If something goes wrong, roll back to the previous version instantly.
Every deploy step is recorded. If something goes wrong — you'll see exactly where.
Latest push
Pushes to main
echo "==> Installing PHP dependencies"
$PHP $(which composer) install --no-dev
echo "==> Building frontend assets"
npm ci && npm run build
echo "==> Running migrations"
$PHP artisan migrate --force
echo "==> Generating sitemap"
$PHP artisan sitemap:generate
echo "==> Activating new release"
mv -Tf "$BASE/current.tmp" "$BASE/current"
→ deploykin: webhook received · push main
==> Cloning repository ✓
==> Linking shared paths ✓
==> Installing PHP dependencies ✓
==> Building frontend assets
error during build: Could not resolve "./Cart.vue"
✗ Deploy script failed · 63 s
→ current not switched — the site stays on the previous release
Zero-downtime
Your site runs without interruption — even during an update. Every deploy is built in its own directory under releases/, and only a finished build becomes current — the symlink is switched atomically and PHP-FPM reloads the code without a restart.
shared/
No repository
Not every project has a repository. Put the archive into the site directory and ask the assistant or an MCP agent to deploy it — Deploykin unpacks it into a new release and swaps current atomically, exactly as it does for a Git deploy.
Deploy release.tar.gz: composer and migrations
deploy_from_archive
run_composer
run_migrations
What happens to the archive
Supported formats
.tar.gz
.tgz
.tar.xz
.txz
.tar.bz2
.tbz2
.tar
.zip
And more
The small things people usually write their own deploy scripts for are already in the panel.
Deploying a site also deploys the linked sites and worker nodes — right away or with a delay.
One deploy script with variables is applied to every site in the cluster.
After a deploy, Horizon and queue workers get a signal and pick up the new code.
A push during a running deploy is not lost — it queues behind the current one.
If a deploy fails, a message goes to your notification channels.
The in-panel assistant and MCP clients such as Claude and Cursor trigger deploys and read and edit the script.
In the panel 203.0.113.21 Connect done in 4 min 52 s
Connect GitHub, pick a branch — and every push automatically updates your site.
We use cookies and the Yandex Metrica web-analytics service (including Session Replay) to improve the site. Details are in the privacy policy.