Protection layers
The same VPS — before and after connecting.
Deploykin sets up part of the protection itself — when you connect a server and create a site. The rest is switched on from the panel when you need it.
SSH access
root with a password, default port 22
Keys only: root login is disabled and SSH moves to a random port
Firewall
Off or not configured — ports are open
UFW is on: inbound is closed, only what is needed stays open
Sites
All run under one user
Each has its own user, home directory and PHP-FPM pool
Security headers
Written by hand into every site's config
X-Frame-Options, X-Content-Type-Options and Referrer-Policy — on every site from the start
Watching the code
Nobody notices changed files
Every hour — a check of files, dependencies and malicious code
- SSL certificates
- Fail2Ban
- CrowdSec · Pro plan
- SSH monitoring
- Basic Auth
- Two-step verification
Panel
Five questions about protection. The answers are in the panel.
Pick a question — the panel opens the screen with the answer. This is a copy of the panel with demo data — click around or watch the tour.
Server
Locked down before the first site.
Deploykin configures sshd and the firewall during setup, then shows every rule and every ban — no iptables and no config editing over SSH.
UFW firewallFlexible firewall rules
by default
Ready-made presets lock the server down in one click, and a custom rule is a port, protocol, policy and a source address or subnet. Rules managed by Deploykin are marked as system rules.
- Presets: block all incoming, SSH only, web traffic, private SSH, database server
- Custom rules with source IP filtering
- Default policy for incoming and outgoing traffic
- The firewall will not turn on without an SSH rule — you cannot lock yourself out
SSH accessKeys instead of passwords, root locked
by default
During setup Deploykin creates a deploykin user with key access, disables root and password login and moves SSH from the default port 22 to a random one.
- Root login is disabled: PermitRootLogin no
- Password login is disabled — or stays, if you need it
- A random SSH port, with port 22 closed in the firewall
- SSH keys: RSA, ED25519, ECDSA
Applied after installation
Fail2Ban · CrowdSecPassword guessing ends in a ban
one click
Automatic IP blocking on password brute-force. Bantime increment for repeat offenders. Nginx filters: HTTP auth, bot search, limit requests.
- Fail2Ban is switched on when the server is created or installed later from packages
- Default threshold: 5 attempts in 10 minutes — a one-hour ban
- The recidive jail bans those who come back for a week
- CrowdSec on the Pro plan and Ubuntu 24.04: a WAF in front of your sites and a community blocklist
SSL certificatesSSL in one click and auto-renewal
one click
Let's Encrypt is issued from the panel in one click and renews itself from then on. Statuses — pending, active, expired, failed — always in view. Alert 14 days before expiration.
- Upload your own certificates (custom upload)
- The certificate covers all site names
- HTTP to HTTPS redirect as soon as the certificate is installed
valid
Oversight
Checks by itself — on a schedule.
Deploykin does not wait for you to open the panel: it checks the sign-in log, site code and certificate dates on a schedule and tells the team when something is wrong.
5minutes
SSH sign-in log
Deploykin remembers the addresses people have signed in from. A sign-in from a new one is reported to the team: who, from which IP and how — with a key or a password.
turned on in server settingssign-in from a new IP — alert to Telegram and email
1hour
A check of every site
composer audit and npm audit, file changes against git and a baseline, a search for web shells and obfuscated code. Excluded paths are configurable.
by defaultnpm audit: 1 warning — alert and report
14 · 7 · 3days
SSL certificate expiry
Alerts 14, 7 and 3 days before expiry — and once the certificate has expired. Let's Encrypt renews automatically.
by default3 days to expiry — alert
90days
Service SSH key
The key Deploykin uses to reach the server is replaced on a schedule — without you doing anything.
by defaultkey replaced — next rotation in 90 days
Site isolation
Breaking into one site does not open the others.
Each site runs under a separate system user with an isolated home directory. Compromising one does not affect the others.
- Directory
/home/shop- PHP-FPM
- own pool
- Directory
/home/blog- PHP-FPM
- own pool
- Directory
/home/crm- PHP-FPM
- own pool
~$ whoami
blog
~$ cat ../shop/.env
cat: ../shop/.env: Permission denied
- Its own home directory, closed to the other sites
- Its own PHP-FPM pool — the site's code runs as its user
- /home and /var/www cannot be listed
- The site terminal opens as the same user
Account and team
Panel sign-in is protected too.
A Deploykin account reaches every server you manage, so signing in to it is protected separately: with a second factor, security keys and a list of active sessions.
- Two-step verification: an authenticator app code and recovery codes
- Security keys and passkeys — passwordless sign-in that cannot be phished
- Sign-in only from your addresses: an office, a VPN or a whole subnet
- Four roles: owner, admin, developer and viewer
- Only the owner and admins grant root access — and the owner is notified right away
Where you are signed in
Key vault
Team SSH keys — in one vault.
Team keys are stored encrypted and rolled out to servers automatically. A new user gets the right keys immediately, and a bulk install pushes them to all servers at once.
- A team vault with key encryption
- Auto-install keys for new server users
- Bulk sync to all servers at once
- Rotation of the Deploykin service key
ED2551912 users · 4 serversED2551912 users · 4 serversRSA 409612 users · 4 serversIn the panel 203.0.113.21 Connect done in 4 min 52 s
Security is on by default.
Connect a server — the firewall, key login and site isolation are configured automatically.
- 7 days free
- No card required
- Human support