I have a vps hosted on Fsthosts in which I have a number of apps and databases. The plan I have for clients who will use the apps on the vps is for them to have their own databases on their own vps which would mean them having their own account with Fasthosts. We have applied for the Fasthosts Partner Programme. So how this arrangement will work - the client will of course be set-up to have their own account with us to use our apps, but we will not hold any data belonging to them - all we will have is details of their admin user(s) - all other data will be held on their own database that will be hosted on their own vps - the idea of this had various reasons, but one of them is security as well as privacy - the reason I say security is because their own vps will have no public exposure - the only access to it will be through via our vps which wll connect to the client's vps via secure tunnel. Now, we are still waiting for Fasthosts to implement out Partner Programme - I really need to start testing this arrangement of integrating with client vps's asap, so am thinking of creating another Fasthosts account and then provisioning a vps on that account which will then act as a test client account - if I were to do this, would it be possible to link my current vps to another vps on the account I am thinking of opening?
Yes, it is entirely possible to link your current VPS to a VPS on a separate Fasthosts account, and doing so is an excellent way to safely test your architecture before the Partner Programme is fully implemented. Because Fasthosts virtual private servers operate independently, they do not rely on account-level bindings to establish secure network connections. [1, 2, 3]
To simulate your intended production workflow—where the client's VPS has zero public exposure and is only reachable via your primary VPS—you can configure this setup using standard networking protocols.
Since the two servers will sit in entirely different account spaces, you cannot use a shared native VLAN or an account-level private switch. Instead, you must build the "secure tunnel" over the internet using software-defined networking: [4]
10.0.0.2) that only your primary VPS can route to. [5]wg0) is active, use the Fasthosts Cloud Panel Firewall Policies to block all public inbound traffic to the client VPS. Ensure the database software on the client VPS is configured to listen only on the local/tunnel private IP address, effectively removing its public exposure. [9, 10]This exact configuration will mirror your future Partner Programme setup perfectly, as the application layer won't care whether the underlying VPS belongs to a partner account or a retail client account.
If you would like to proceed with this test setup, let me know:
I can provide the exact configuration scripts to get your secure tunnel up and running immediately.
[1] https://www.fasthosts.co.uk
[3] https://www.scalahosting.com
[4] https://www.scalahosting.com
[6] https://www.fasthosts.co.uk
[7] https://www.fasthosts.co.uk
[8] https://www.fasthosts.co.uk
[9] https://www.fasthosts.co.uk
[10] https://www.fasthosts.co.uk
[11] https://www.fasthosts.co.uk
[13] https://www.databasemart.com
Yes I plan to use WireGuard - Just a general question that I am wondering about...we want our clients to have their own access to the database on their vps's, but only for the purpose of data migration and exporting data - we need to do this so they my be classed as 'truly independent' from us - may sound a bit strange but the reason we are doing this is because I said before - data privacy as well as security - so, for this arrangement to achieve this status of provisioning a vps for new clients that is 'independent' of our infrastructure, what controls must we provide for the client on their own vps?
To achieve a status where your clients are legally and technically "truly independent," you must shift from a model of "managing their server" to a model of "provisioning their server."
To satisfy data privacy, security, and true independence, you must give the client exclusive ownership of the cryptographic keys, access logs, and administrative privileges on their VPS.
You cannot hold the master keys to their infrastructure if they are to be independent data controllers.
root or sudo administrative credentials.app_user), not a root system account.To ensure they can leave or back up their data without your intervention, they need standalone tools.
.sql or .csv files) are deposited. The client can log in via SFTP over the WireGuard tunnel to download them independently.The client must have ultimate authority over who can talk to their server.
wg-quick down wg0) at any time. This gives them a physical "kill-switch" to sever your app's access to their database if they choose to terminate the relationship.Under strict privacy regulations (like UK GDPR), the data controller must have access to access logs.
mysql.log, postgresql.log) and system access logs (/var/log/auth.log) must be stored locally on their machine, accessible to them, and not forwarded to your primary server.To help map out this architecture, let me know:
Aside from our apps providing the necessary access for clients to access their data, I am not entirely sure what I must set-up for them on their own vps accounts - what I need to establish is the basic makeup of a client account with its own vps - it will be the same OS as ours which is Linux/Ubuntu. I understand the need to hand over certain information so that the client effectively has the 'keys' to the vps and is at liberty to choose who they consent to give access to, including us
To establish a standardized, "independent" client VPS blueprint running Ubuntu, you need to strip away any hardcoded dependencies on your infrastructure. The basic makeup of the client's VPS must consist of four core operational layers: the Host OS layer, the Network Tunnel layer, the Database layer, and the Client Self-Service layer.
Here is the exact technical blueprint of what must be set up on every client VPS to achieve this.
This layer contains the system-level access and the absolute master keys to the virtual machine.
clientadmin) must be created. During provisioning, a temporary password is set, or a temporary SSH key is injected.~/.ssh/authorized_keys.This layer manages the secure highway back to your main application VPS, while strictly controlling inbound traffic.
The WireGuard Configuration (/etc/wireguard/wg0.conf): This file defines the client's unique private IP (e.g., 10.0.0.2) and points strictly to your main app VPS public IP as its "Peer".
The Local Firewall (UFW): Ubuntu’s built-in Uncomplicated Firewall (UFW) must be enabled with strict rules:
DEFAULT DENY for all incoming traffic.ALLOW incoming traffic on the custom SSH port—but only from the client’s corporate office IP address.ALLOW incoming traffic to the database port (e.g., 3306 or 5432)—but only via the wg0 network interface (your app tunnel).Public Blindness: No database ports are exposed to the public internet.
This is where the actual application data lives, partitioned tightly by user privileges.
fh_app_user). This user is granted data read/write permissions only for the client's specific production database and is restricted to connecting from your app's WireGuard IP (e.g., 10.0.0.1). It has no rights to create new databases or drop system tables.client_db_admin) with full ALL PRIVILEGES over their databases. The client will use this specific username and password to perform migrations, run queries, or export data.To prove independence, the client must be able to pull their data without asking you to run commands for them.
mysqldump) and saves it to an isolated folder on their disk (like /home/clientadmin/backups/). This ensures they always have a running historical log of their data that you cannot alter or delete.When a new client is onboarded, your setup is complete when you pass them a single secure file or document containing:
sudo systemctl stop wg-quick@wg0 to instantly disconnect your apps from their server if they ever wish to revoke your consent).To help tailor the exact setup scripts, let me know:
Yes we will manually set-up these vps's ourselves, therefore, it is imperative that we have a blueprint to work from - I am wondering if it would be possible to conduct the set-up process from our VPS once we have the client's OS on their vps provisioned? I am asking this because on our vps, we have opencode operating and provided I have details of the blueprint, I can then give our agent instructions to execute the set-up procedure
Yes, it is entirely possible to conduct the setup process remotely from your VPS, and using OpenCode to drive this via an AI agent is an incredibly efficient approach. Because OpenCode natively executes bash tasks and handles system automation, it is perfectly suited to configure an external "blank slate" server over SSH. [1, 2, 3, 4, 5]
The remote setup operates smoothly because Linux/Ubuntu servers are built for remote management. Your primary VPS simply acts as the command center, connecting to the client's new VPS via its temporary public IP to perform the installations. [6]
To ensure your OpenCode agent executes the setup flawlessly without breaking the system, your instructions to the agent must be structured sequentially into specific execution blocks.
Before running code, your agent needs to know where it is connecting. You must provide the agent with:
The agent's first step will be to verify connectivity and install sshpass (or use a private key) to run remote commands without manual password prompts:
# Agent test command to confirm target is reachable via SSH
ssh -o StrictHostKeyChecking=no root@CLIENT_IP "echo 'Connection successful'"
The agent will execute commands on the client VPS by piping them over SSH. It should run an update and enforce immediate public blindness: [4]
# Update repositories and install essential networking packages
ssh root@CLIENT_IP "apt-get update && apt-get upgrade -y && apt-get install -y ufw wireguard"
# Lock down the public firewall immediately
ssh root@CLIENT_IP "ufw default deny incoming && ufw default allow outgoing"
ssh root@CLIENT_IP "ufw allow 22/tcp" # Keep SSH open for now
ssh root@CLIENT_IP "ufw --force enable"
Your agent will need to handle crypto-key creation and write the /etc/wireguard/wg0.conf configuration on the client machine: [4]
# Command the agent to generate WireGuard keys directly on the client machine
ssh root@CLIENT_IP "wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey"
# Instruct the agent to write out the configuration pointing back to your main app VPS
# It will map the client to a static tunnel IP like 10.0.0.2
Next, the agent installs the database engine (e.g., MySQL or PostgreSQL) and binds it securely to the tunnel network interface so it never touches the public internet: [4]
ssh root@CLIENT_IP "apt-get install -y mysql-server"
# Agent script to modify /etc/mysql/mysql.conf.d/mysqld.cnf
# Shifting 'bind-address = 127.0.0.1' to 'bind-address = 0.0.0.0' or the specific WireGuard IP
ssh root@CLIENT_IP "systemctl restart mysql"
To fulfill the requirement of absolute data privacy and customer ownership, the agent builds a clean database administrator user account specifically for the client: [4]
# Agent creates the master client DB credentials
ssh root@CLIENT_IP "mysql -e \"CREATE USER 'client_db_admin'@'%' IDENTIFIED BY 'RandomSecurePassword';\""
ssh root@CLIENT_IP "mysql -e \"GRANT ALL PRIVILEGES ON *.* TO 'client_db_admin'@'%' WITH GRANT OPTION;\""
When initializing the session for your agent, you can feed these requirements directly into its operational parameters by creating an agents.md context file or passing an upfront prompt in Build Mode: [2, 7]
"You are an expert DevOps engineer agent. Your task is to provision a brand-new, remote Ubuntu VPS to serve as an independent client database node. You will communicate with the target server strictly over SSH using the credentials supplied. You must install WireGuard, install the database engine, configure UFW to block all non-tunnel database traffic, and create a master database admin account for the client. Confirm your plan before executing the first bash sequence." [2, 3, 4, 5]
This hands-off architecture saves time. Your team only needs to click "provision" in Fasthosts, grab the temporary IP, and feed it straight to the OpenCode engine to handle the rest.
To refine the instructions for your agent, let me know:
We are still waiting for Fasthosts to set up the Partnership Programme for our account - I am thinking that we don't have to wait for the Partnership Programme to be in place for setting-up a test client account. By that I mean creating another account for Fasthosts and acquiring a vps and then configuring it in the way we have discussed here?
You do not have to wait for the Partner Programme to be approved to start testing.
Because virtual private servers operate on standard networking protocols over the internet, a Fasthosts VPS on a standard retail account functions exactly the same as a VPS provisioned through a partner portal. Opening a separate retail account now is the best way to validate your blueprint immediately.
When setting up this independent test environment, you should navigate a few key structural details to ensure it accurately mirrors your final production workflow.
To ensure the test client account acts as a true "independent" entity during your trials, set it up with clear boundaries:
While the Partner Programme primarily gives you billing discounts, referral rewards, and single-pane-of-glass client management tools, it does not alter the underlying server technology. [1, 2]
By manually provisioning the test VPS now, you can practice the exact operational handoff you will use later:
Once your Fasthosts Partner Programme is active, you will not need to delete or rebuild your test server. The Fasthosts platform allows you to transfer services directly between distinct accounts. You will easily be able to link or migrate this standalone test environment into your primary Partner Dashboard profile without breaking your established WireGuard network paths. [3]
If you want to prepare the automated setup files for your testing agent, let me know:
10.0.0.0/24).I can provide the exact code blocks your agent will need to execute the moment your test VPS goes live.
[1] https://www.fasthosts.co.uk