Manage a VPS

What is this service about?

A Virtual Private Server (VPS) is a virtual machine with its own operating system, allocated resources and network addresses. Use it to run websites, applications, databases, development environments or other software that you administer.

The BlazingFast portal manages the virtual machine: its power, access information, supported operating system installations, recovery points and available network controls. Inside the VPS, you are responsible for configuring the operating system, installing and updating applications, managing accounts and checking that your services work. A running VPS does not automatically mean that its website, database or email service is healthy.

This guide explains each control, when to use it and how to check the result. Available controls depend on your plan, location, operating system, permissions and the service's current state. A feature described here may not be offered for every VPS.

Before you make changes

Sign in to the customer portal, open your VPS from your services or VPS list, and confirm its service ID, hostname and IP address. Work on the correct server, especially when you own several similar plans.

For production maintenance, arrange a maintenance window, save active work and check that you have a recent usable backup. Keep a separate recovery copy for important data. Reinstalling, restoring and force-stopping a VPS can interrupt services or destroy changes; the warnings below are part of the procedure, not optional advice.

Use the access details displayed for your own VPS. Any example using 203.0.113.10 is illustrative, not a real server address.

1. Check status and service information

Purpose: Establish whether the VPS has finished provisioning, whether it is powered on and which resources and addresses belong to it.

1. Open the VPS management page and read the service status and runtime/power status separately.
2. Review Server Information for the operating system, hostname, location and plan.
3. Expand Access Credentials to find assigned IPv4 and, when available, IPv6 addresses.
4. Check whether an installation, backup, restore or other task is still running. Refresh the page or use its refresh control after the task has had time to complete.

Check: The service identity, assigned addresses and latest task result match what you expect. An Active service is not proof that the VM is running; a Running VM is not proof that its application is responding.

2. Start, reboot or force-stop the VPS

Purpose: Control the virtual machine's power. These actions interrupt guest workloads and must be chosen carefully.

1. Save work and, for a production server, notify users before a disruptive action. Use a graceful shutdown or restart from inside the operating system for routine maintenance whenever possible.
2. Check the current runtime status. Select Start to power on a stopped VPS.
3. Use Reboot only after preparing for an abrupt restart: the portal identifies this action as Hard Reboot (Reset). It is not a graceful operating-system reboot.
4. Use Force Stop only when an immediate power-off is necessary, such as an unresponsive guest. This is similar to pulling the power plug and may lose unsaved data or require filesystem/database recovery.
5. Confirm any warning, submit the action once and wait for the task to settle before refreshing the runtime status.

Check: The expected power state appears and the guest has completed booting. After a reset, verify the filesystem, database and application, not only the power indicator. If a control is disabled, first check for pending tasks, permissions or a suspended service.

Stopping a VPS does not cancel the service, remove an invoice or stop renewal charges. Do not use Force Stop as a substitute for cancellation.

3. Connect using SSH or Remote Desktop

Purpose: Log in to the guest operating system to install software and administer your server.

1. Expand Access Credentials and copy the assigned address and the access details shown for your operating system.
2. For Linux, use your SSH client and the portal's SSH command. A typical initial command is ssh root@203.0.113.10, but use the actual username, IP and port configured on your server.
3. Authenticate with the corresponding private SSH key or with the password if password authentication is enabled. For Windows, use Remote Desktop with the displayed address and the Administrator account unless you have configured another account.
4. Allow only the required access through both the VPS firewall and the guest operating system's firewall. Restrict administrative ports to trusted source addresses where practical.
5. After connecting, verify the server hostname and operating system before making changes. Store credentials securely and create an appropriate day-to-day administrator account.

Check: You can authenticate to the intended VPS. If the connection times out, check runtime status, routing, both firewalls and whether SSH/RDP is listening. If authentication fails, check the username, key and guest authentication policy instead of repeatedly changing network settings.

An SSH host-key warning after a deliberate reinstall may reflect a new server identity. Verify the change before updating your client's trusted host entry; do not routinely disable host-key verification. Never paste passwords or private keys into a URL, public screenshot or support ticket.

4. Use the browser console

Purpose: View the guest's screen when normal SSH/RDP access is unavailable, for example after a boot or network configuration problem.

1. Open the VPS management page and confirm the VM is running, or start it if appropriate.
2. Select the console button. Allow the portal's console window if your browser blocks the popup.
3. Wait for the console to connect, then use the guest operating system's normal login credentials.
4. Inspect the boot messages or correct the guest's network, firewall or SSH/RDP configuration as needed. Keep the console available while testing normal access in a separate window.

Check: The console shows a responsive guest and you can complete a normal login. Console access does not bypass the operating system's authentication. A disconnected console alone does not prove that the VM or its public network is down; refresh the console session and check the service's task state.

5. Reset a lost administrator password

Purpose: Request a replacement guest administrator password when the supported password-reset workflow is available.

1. Open Access Credentials and choose Request password change, or use the Reset Password quick action.
2. Confirm the request and wait for the returned password or task result. Save the new password in your password manager before leaving the result screen.
3. Read the Reboot required notice. The change needs the supported boot-time configuration to apply; it is not necessarily effective immediately in the running guest.
4. Schedule the interruption and follow the offered restart/start action when ready. Treat a reset-style restart as disruptive, just like the hard reboot described above.
5. After boot, test a new login using the correct Linux or Windows administrator account and keep any working recovery session open until the test succeeds.

Check: The new password authenticates after the required boot step. A password reset does not necessarily enable SSH password authentication on a server configured for key-only access. If a custom image cannot apply the change, use the console and contact support with the task error; do not reinstall merely to test a password.

6. Manage SSH-key access safely

Purpose: Use public-key authentication without exposing the private key or accidentally removing your only working login method.

1. Prepare an SSH key pair on your own device and keep its private key there. Only the public key belongs in the portal or on the server.
2. For a new installation, open Reinstall, choose a supported Cloud-init Linux/BSD image and select Select from saved keys or Paste a public key. Read section 8 before proceeding: reinstalling is destructive and is not the normal way to rotate a key.
3. For an existing installation, first check the configured key shown in Access Credentials. Adding or changing a saved account key does not automatically update every existing VPS, and this section does not necessarily offer a key-edit button.
4. To rotate access on an existing server, use its supported SSH-key update API where appropriate, or add the new public key to the correct guest account's authorized keys through a working administrator session. Keep the old access method until a separate session using the new key succeeds.
5. Once verified, remove only the obsolete key from the intended guest account and review password-authentication policy if needed.

Check: A fresh connection with the new private key works without relying on an already-open SSH session. Key injection depends on the image's support; it is not a general Windows login mechanism. Do not upload private keys or assume deleting an account-level saved key revokes copies already installed inside a guest.

7. Change the hostname

Purpose: Give the VPS a recognisable operating-system hostname for administration and monitoring.

1. In Server Information, find Hostname and choose its edit control.
2. Enter the intended hostname and save the change using the confirmation control.
3. Read any reboot prompt and apply the change during an appropriate maintenance window.
4. After the task and any required reboot, check the hostname from inside the guest and in the portal. Review application settings that depend on the previous name.

Check: The intended name is displayed and the guest uses it after the required apply step. A hostname change does not register a domain, create public DNS records or automatically configure email reverse DNS.

8. Reinstall the operating system

Purpose: Replace the current guest installation with a fresh supported operating system. Use this to deliberately rebuild a server, not as a harmless troubleshooting action.

Destructive operation: Reinstalling wipes the VPS's existing installation and permanently deletes its existing snapshots. A snapshot on this VPS is not protection against reinstalling it. Verify an independent recovery copy, including any attached storage that matters, before continuing.

1. Save the data, configuration, access information and application secrets you need to recover. Confirm the correct service ID and plan a maintenance window.
2. Select Reinstall to open Reinstall Operating System. Choose an available operating-system distribution and version for this service's location.
3. Enter an optional Hostname, or leave it blank to retain the current hostname as indicated by the form.
4. For supported Cloud-init Linux/BSD images, choose the SSH-key source: None, Select from saved keys, or Paste a public key. Review Enable password authentication for root where offered. Do not select key-only access without a usable key.
5. Review Firewall policy for this reinstall. Keep the current policy or select the intended saved policy. Default (allow all) is permissive, not a security recommendation; ensure you retain an appropriate login path.
6. Read the warning, type REINSTALL in the confirmation field and select Reinstall OS only when ready to erase the existing installation.
7. Wait for the installation task to finish. Securely record any new credentials, then check the newly provisioned addresses and access details rather than assuming all previous settings survived.

Check: The service is active, the guest boots into the selected OS, console and normal login work, and the expected firewall is applied. Reinstall your applications and restore data separately as needed. A clean OS installation does not restore your previous website or database automatically.

Snapshots and backups: choose the right tool

Neither a VM snapshot nor a VM backup automatically guarantees application-consistent database recovery. Quiesce applications or use the database's own backup procedure when required, and verify the recovery method before relying on it.

9. Create, restore or delete a snapshot

Purpose: Keep a short-term rollback point around a change to the VM.

1. Open the VPS's backups and snapshots section and review its snapshot allowance and any running jobs.
2. Before creating a point, save work and prepare applications for a consistent capture. Enter an optional snapshot name and description that identify the change.
3. Select Create snapshot and wait until creation finishes successfully before beginning the maintenance it is meant to protect.
4. To roll back, select the intended snapshot's Restore action, verify the name/time, read the interruption and overwrite warnings, and confirm only after saving any newer data you still need.
5. Wait for restoration to finish, then check runtime state, login, application data and services. If the VM must be started, do so after the restore completes.
6. To remove a no-longer-needed point, use its delete action and confirm the exact snapshot. Deletion cannot be undone from the portal.

Check: The intended snapshot appears after successful creation, or the expected guest state returns after restoration. RAM capture and snapshot availability depend on provider/storage support and VM conditions; do not rely on a snapshot to preserve every in-memory transaction. Restoring replaces the current VM state with the selected point and loses newer changes in the restored scope.

10. Run, cancel or delete a manual backup

Purpose: Create a recovery file now, before maintenance or another important change.

1. Open the backups and snapshots section, check available storage/quota and ensure no conflicting operation is running.
2. If the form offers Include storage volumes, select it when this run must cover attached storage volumes. Do not assume a root-disk backup includes every attached disk.
3. Select Run backup, or use the corresponding quick action, and monitor the job until it succeeds.
4. Check the resulting backup file's timestamp and size. Retain any application-level backups needed for reliable database recovery.
5. If you must stop a running backup, choose Cancel and confirm. Wait for the job status to settle; cancellation support can vary and an incomplete file is not a successful recovery copy.
6. To free space, select the delete action for an explicitly identified old backup file and confirm. First ensure you are not deleting the only usable recovery point.

Check: A completed backup file is listed for the intended time and scope, without a failed job result. A queued or running job is not a completed backup. Manual files consume storage quota, and deleting one is irreversible through the portal.

11. Schedule automatic backups and retention

Purpose: Create regular recovery copies and control how many automatic backups are retained.

1. In the backups section, enable Schedule where the feature is available for your VPS.
2. Choose Daily or Weekly. For a weekly schedule, choose the day as well.
3. Set Hour, Minute and Timezone deliberately, preferably for a low-activity period. These controls do not offer an hourly schedule.
4. Set Keep backups to the offered number of automatic recovery copies you want retained. This is a count of backups, not a number of days, and the automatic-retention setting does not manage manual backups.
5. Allow the settings to save, then re-open or refresh the section to check the saved choices. These schedule controls save changes as you make them; there is no separate Save schedule button in this workflow.
6. After the first scheduled run, review its last-run result, any error and the new backup file. Continue checking available quota and recent successful jobs.

Check: The saved schedule uses your intended timezone and a completed automatic backup appears after its scheduled run. The manual Include storage volumes checkbox applies to that manual run; it is not proof that scheduled jobs cover attached volumes. Verify scheduled coverage separately before relying on it.

To stop future scheduled runs, turn off Schedule and check that the setting remains disabled. This is separate from cancelling a job already in progress and does not by itself delete existing backup files.

12. Restore a backup

Purpose: Replace the current VM disk with a selected earlier backup after a failure or unwanted change.

Destructive operation: Restoring overwrites the current VM disk. The VM will be force-stopped before restoration if it is running, and all snapshots will be lost. Preserve newer data first and arrange downtime. Check the backup's coverage; do not assume disks not included in that backup will be restored with it.

1. Identify the correct service and backup file, including its timestamp, size and known coverage. Choose its Restore action.
2. Read Confirm restore and the overwrite/force-stop warnings. Make a separate copy of current data if you might still need it.
3. Choose whether Start VM after restore should be enabled. Leave it off when the guest must be inspected or prepared before it resumes production work.
4. Confirm the offered restore action, such as Force stop, restore and start for a running VM when automatic start is selected. Submit it once.
5. Wait for successful completion before starting other operations. Start the VM if it was intentionally left off and you are ready.
6. Test console/login, addresses, firewall behavior and actual applications. Confirm the restored data's timestamp and review scheduled jobs, secrets and access changes made since the recovery point.

Check: The expected earlier system and data are present and application checks succeed. The restored guest can contain older passwords, keys, certificates and application configuration; account for that when logging in and bringing it back online. A running VM alone is not a completed recovery test.

13. Configure firewall rules and saved policies

Purpose: Control which network traffic is permitted to reach or leave the VPS at the platform firewall layer.

1. Open the Firewall section and review whether it is enabled, its current policy, default inbound/outbound actions and existing rules. Keep a working console session available before changing administrative access.
2. To reuse a saved configuration, select the intended policy under Saved firewall policies and choose Apply. Review its rules before applying; do not assume the old rules will remain unchanged.
3. To maintain reusable policies, choose Manage, then create or edit the appropriate saved policy and its rules. Marking a policy as primary is not proof that every existing VPS has already been changed; apply and verify the intended policy on each service.
4. To add a service-specific rule, choose Add rule, set direction, action and protocol, then the relevant ports and optional source/destination restrictions. For example, permit your configured SSH port only from a trusted administration address, or permit the required web ports for a public website.
5. Add a useful comment, review whether the rule is enabled and choose Create rule or Save changes. Review rule order and any conflicting rules. Use the row controls to edit, disable or delete only the intended entry.
6. Before selecting a default-deny inbound action in Firewall options, ensure the necessary administration and application allow rules exist. Preserve required outbound access, including DNS and application dependencies, if restricting egress.
7. Select Save options for option changes, wait for the result and test from a separate client. Do not close your recovery access until the required traffic works and unwanted traffic is blocked.

Check: The selected policy and options remain applied after refresh. A new SSH/RDP session from the permitted source succeeds, and the intended application ports behave as expected. The platform firewall, guest firewall and application listener are separate controls; allowing a port in one does not open it in the others.

Avoid exposing administrative services to every source merely to make a test pass. If you lock yourself out, use the console to inspect the guest and correct the specific platform policy through the portal; do not remove unrelated protections blindly.

14. Prepare and attach a private network

Purpose: Connect eligible resources over the offered private network, for example an application VPS and its database, without using public addresses for their internal traffic.

1. Open the private-network section if offered for this service. Check the location and eligible connected resources. The feature requires at least two eligible VPS or managed-database resources in the same cluster before NIC attachment can be enabled.
2. Choose Prepare private network when needed and wait for the network to be ready. Preparation alone does not attach a NIC to the VPS.
3. Select Attach private NIC when available. Wait for the queued attachment to finish and note the assigned private address, subnet and MTU shown by the portal.
4. Follow the reboot notice after the attachment is ready so supported Cloud-init configuration can apply the address. Plan the guest interruption rather than repeatedly attaching NICs.
5. Inside the guest, verify the new interface and assigned address. Configure only the intended application to use that address, with appropriate platform and guest firewall rules.
6. From the other eligible resource, test the required application connection over the private addresses. Confirm that public access still works where it is intended.

Check: Both resources have the expected private connectivity and the application uses it successfully. Do not replace the public default gateway or assume private-network attachment supplies Internet access or connectivity to another cluster.

To detach it, first move dependent traffic elsewhere, choose Detach private NIC, read the confirmation and wait for completion. Detachment interrupts applications relying on that interface; it is not a request to remove the VPS's public NIC.

15. Review resource usage and troubleshoot slowness

Purpose: Compare VM-level CPU, memory and network activity over time and decide what to inspect inside the guest.

1. Expand Usage and select the available period, such as hour, day, week, month or year.
2. Compare CPU, memory and network activity with the time users reported the problem. Distinguish network totals/counters from a transfer-rate measurement.
3. Check the guest's processes, filesystem free space, database health, application logs and network listeners using SSH or the console. These are not all represented by the portal charts.
4. If graphs are missing or stale, refresh the page and compare current runtime status and guest responsiveness. Do not assume missing chart data means the VPS is powered off.
5. Record the timeframe, timezone and relevant symptoms if you need support. Avoid sending application secrets or unnecessary customer data with logs.

Check: Your conclusion is supported by current guest/application tests as well as resource history. Low CPU alone does not prove an application is healthy, and high memory usage alone does not identify the process or establish an infrastructure failure.

16. Change the plan or renew the service

Purpose: Request available resource changes and maintain the service's paid term without confusing billing actions with VM power operations.

1. Review the current plan and billing dates. Under Server Information, choose Change plan if available.
2. Compare the offered plans and their CPU, RAM and disk resources. Review Keep extra root disk where offered; do not assume a smaller plan will safely shrink an existing filesystem or disk.
3. Review the price adjustment and confirmation. Use Apply now for an eligible no-payment change, or Continue to payment and complete the required invoice. If an unpaid invoice already exists, use View invoice rather than submitting duplicates.
4. Wait for the operation to complete, then check the new resources in the portal and guest. Arrange downtime if the offered operation requires it; do not assume every change is online or changes the server's location.
5. To extend the service, choose Renew, select the offered period, review the charge and continue to payment. Check the existing invoice first if the portal presents one.
6. After payment processing, verify the invoice and service billing dates. If a billing-cycle control is offered for your service, review its terms separately before confirming; renewal, cycle changes and plan changes are different operations.

Check: The intended invoice is settled and the requested plan or renewal is reflected after processing. Stopping the VM does not stop billing. For cancellation or a suspended/terminated service, follow the available account/support workflow; do not assume data and backups remain recoverable indefinitely after termination.

Quick troubleshooting guide

What to send to support

1. Provide the service ID, the action you attempted and the exact error or failed task identifier.
2. Include when it happened and your timezone, whether the service is active and whether the VM is running.
3. State whether the console works and whether the problem affects power, login, networking, backup/restore or a specific application.
4. Describe recent relevant changes and which checks above you completed. For a website, include the hostname and affected path without passwords or secret query parameters.

Never send private SSH keys, administrator passwords, API tokens or database credentials. Do not delete backups, reinstall or repeat a failed restore merely to gather evidence.

For more account-access context, see Service credentials and console access. For public domain routing and website protection, see Manage DNS and website protection.