Server user guide

1. What a server is

A server is a VPS bought from a cloud provider on your behalf, provisioned and then managed from the panel: applications, databases, domains, backups, firewall, monitoring and SSH access all in one place. You own the machine — SharkCluster is the control plane over it.

2. Creating a server

Servers → + CREATE SERVER.

The form is a single page that fills in as you go. Each choice narrows the next.

Step 1 — Technology

What the server is for. This decides the image and the stack installed: application stacks (PHP/Laravel, Node, Python, WordPress and similar), a Docker host, or a plain server you manage yourself.

Your choice here affects which sections appear later — a Docker host gets Containers, an application server gets Applications.

Step 2 — Plan and region

• RAM slider — drag to the memory you need; the plan list filters to match.
• Recommended plans — the closest fits across providers, with vCPU, RAM, storage and monthly price on each card.
• See all matching plans — the full list when the recommendations are not what you want.
• Region — click to open the region picker. Choose the region closest to your users; it cannot be changed after the server is created.

Providers are shown together, so the same RAM can be compared across them on price and location in one view.

Step 3 — Add-ons

Optional extras selected before creation, including backups. See Backups for what the backup add-on covers.

Step 4 — Web server and stack options

Where the technology needs it: web server choice, PHP or runtime version, and database engine.

Step 5 — Summary

A final review — technology, plan, region, add-ons and the monthly price — before you commit. This is the last screen before the server is ordered and billing starts.

Step 6 — Installation

The page becomes an installation log: the server is ordered, SSH becomes available, packages install, the stack is configured. Typically a few minutes. You can leave the page; the server appears in the list as Installing and moves to Running when it finishes.

Billing

Billing begins when the server is created and follows the provider:

Prepaid providers ask for payment first, so creation stops until it clears. Servers appear on Billing → Overview under Servers, prorated for the days they ran.

3. The server list

Servers shows every server as a card:

• Name and status (Running, Installing, Stopped)
• Specification — vCPU, RAM, storage
• IP address, with copy
• Key — SSH access indicator
• Region, with flag
• Created date
• APPLICATIONS n — the applications on it, listed as small cards beneath with their URLs, copy and open buttons
• MANAGE — the actions below

Above the list: search by application name or IP, sort, filter by status, filter by provider, a refresh control, and RECOVER SERVER for restoring a deleted server where the provider still holds it.

The MANAGE menu

Manageability

A server carries one of three states, shown on the card:

• Panel Manageable — SharkCluster manages the stack; every section works.
• Partially Manageable — some functions are unavailable.
• Root — root access has been granted, so the panel no longer guarantees the configuration and management from the panel is restricted.

Granting root is deliberate and one-way in practice: once someone can change the machine by hand, the panel cannot promise its own view is accurate.

4. Server detail

Open a server to reach the sections in the left sidebar. What appears depends on the server's technology and your permissions — a team member without a permission does not see that section.

4.1 Monitoring

The landing section. CPU, memory, disk and network over a selectable window, plus current load and uptime. Start here when something is slow.

4.2 Packages and Services

What is installed and what is running — versions, service status, and controls to start, stop or restart services.

4.3 Caching

Cache layers for the stack (such as Redis or Memcached where the technology supports it): enable, configure and clear.

4.4 Other Services

Additional services outside the core stack, installed and managed per server.

4.5 Scaling

Change the server's size. Scaling resizes the underlying VPS; the provider may require a reboot, and the price changes from that point.

4.6 Volumes

Attach, detach and manage block storage volumes — extra disk independent of the server's own, useful when data outgrows the plan.

4.7 Infracaptain

The Infracaptain integration for servers running it.

4.8 Access

Who may reach this server and how — panel users, team members and their permissions on this server.

4.9 SSH Key

Manage SSH keys authorised for the server. Add a key here rather than editing authorized_keys by hand, so the panel's view stays accurate.

4.10 Firewall

Inbound rules: port, protocol and allowed sources. Everything not opened is closed. Open only what an application needs — a database port open to the world is the most common avoidable exposure.

4.11 Backup

Server backups and images.

• Automatic schedule — None, Daily, Weekly, 14 Days, Monthly, with a time and (for weekly) a day. The header shows when the next backup runs.
• Retention — only the latest N are kept; older ones are removed.
• Local and offsite — local backups are free and live with the server; offsite copies go to object storage, survive losing the server, and are billed per GB on the monthly invoice. You confirm before enabling offsite.
• Backup now, restore, and delete, each with confirmation.

Backups are also where snapshots and server images are managed, and where a portable backup can be produced for moving a server elsewhere.

4.12 Applications

The applications on this server: create, open, and manage each one. An application has its own detail page with deployment, domains, SSL, backups and restore, database credentials, and a database manager.

4.13 Database

The databases on this server, their users and credentials, and a web database manager.

4.14 Cronjob

Scheduled tasks: command, schedule, and run history.

4.15 Domains

Domains and subdomains pointed at this server, DNS records where managed, and SSL certificates.

4.16 Containers

For Docker hosts: the containers running on the server, their state, logs and lifecycle.

4.17 Supabase

The Supabase integration for servers running it.

4.18 Health Alerts

Thresholds that raise an alert — CPU, memory, disk — and where notifications go. Set disk alerts early: a full disk stops a server in ways that look like unrelated failures.

5. Recommended first hour

1. 1Create the server — technology, plan, region, add-ons, review, confirm.
2. 2Wait for installation to finish; the card turns Running.
3. 3Firewall — open only the ports you need.
4. 4SSH Key — add your key if you want shell access.
5. 5Domains — point a domain and issue SSL.
6. 6Applications — create your first application.
7. 7Backup — set a schedule, and decide on offsite.
8. 8Health Alerts — set a disk threshold.
9. 9Restore a backup once, so you know the path works before you need it.

6. Things worth knowing

• A stopped server still costs money. Providers bill for allocated resources whether or not the machine is powered on. Only deleting it stops the charge.
• The region cannot be changed after creation. Moving means creating a new server and migrating.
• Granting root changes the relationship. The panel can no longer guarantee the configuration, and the server is marked accordingly.
• Deleting a server is permanent at the provider. RECOVER SERVER only works while the provider still holds the resource.
• Offsite backups are billed per GB, local ones are free. The difference matters: a local backup dies with the server it is protecting.

7. Where to look when something is wrong

Note on this document

Section names, list actions and the create flow are taken from the panel's own code, so they match what a customer sees. The descriptions of what each section does are written at the level a user needs; individual sections that carry many options — Applications, Domains, Backup — deserve their own detailed pages, and this guide is the map to them rather than a replacement.