Cloudy Pad: putting a Sunshine or Wolf game server on any cloud you already pay for

Cloudy Pad provisions the machine, it does not sell you the games

The pitch is that you keep control of both the hardware and the software. Cloudy Pad deploys a cloud gaming instance on your own servers, your own machines, or directly in a cloud provider, and then you sign into your own Steam, Epic, GOG or other game accounts on that instance. The stated point is that you do not need a powerful gaming machine at home and you do not need a monthly subscription for a hosted service. The difference from the hosted platforms it positions itself against is structural rather than cosmetic: the instance is billed by the hour from your own provider account, the launcher logins are yours, and the software running on the box is a streaming server you chose rather than a curated catalogue. What you trade away is everything a managed service handles for you, from driver updates to catalogue curation.

Sunshine or Wolf on the server, Moonlight on the client

Cloudy Pad is not itself the video game streaming server. It deploys one of two existing implementations, Sunshine or Wolf, and the machine you play on runs the Moonlight client. That division matters when you plan the network path, because the client is where the decode happens and the server is where the encode happens. If you deploy on a provider you do not own, you are choosing a GPU instance and a region, and the latency between the two ends is outside the control of the tool. The launcher side is a fixed list rather than an open field: Steam, Epic, GOG, Heroic and Lutris are the supported launchers. The repository contains a Dockerfile and a containers directory, which is where the server images are assembled, and an ansible directory that holds the playbooks used to configure the instance once it exists.

Spot instances and egress limits are the real cost levers

The economics section of the documentation is the part that separates a hobby server from a subscription you pay every month. Four mechanisms are named. Cost alerts can be set up automatically to avoid overspending. Spot instances are described as up to 90% cheaper than on demand instances, at the price of the instance being reclaimable. Network speed can be controlled to limit egress cost on providers that charge for outbound transfer, which matters because a game stream is outbound traffic for the whole session. The headline figure given is about 15 dollars a month or less for 30 hours of play. Two caveats are visible in those same bullets. Spot instances can be interrupted, which is a problem for a machine that is meant to be waiting for you to log in. And the estimate assumes the play happens in the region nearest to the client, since the same bytes are billed differently depending on where the instance sits relative to you.

Two ways in: a CLI deployment path and a browser app

The getting started material splits into two routes. One is a self-deployed instance via CLI, with the steps at the Cloudy Pad documentation site. The other is the Cloudy Pad App, which the project describes as deploying your instance in seconds from your browser. For anyone already working in a terminal, the CLI is the one to look at, and the repository makes its shape clear. The package.json exposes a single binary named cloudypad, and the source tree has a cli directory behind it. The commands themselves are not spelled out in the README, which points to the documentation site instead, so the exact invocation sequence has to be taken from there rather than guessed at. For questions and known problems, the documentation has an FAQ and known issues page, and the README also points at the GitHub issue tracker and a Discord chat.

The build is TypeScript, Pulumi and Ansible in that order

Looking at the repository layout tells you what the tool is made of before you read a line of the documentation. The primary language is TypeScript on NodeJS, and the cloud providers are reached through their own SDKs: the AWS SDK client packages for EC2, S3, STS, account and service quotas, the Azure ARM packages for compute, network, quota and subscriptions, and the Google Cloud compute and resource manager libraries. Infrastructure is described as Pulumi, an Infrastructure as Code tool like Terraform that uses real TypeScript code, and configuration of the running instance is Ansible. The package.json scripts show the build and test cycle. The build compiles with tsc and then copies the ansible directory into the distribution.

"scripts": {
  "test": "mocha",
  "build": "rm -rf dist/ && tsc -p tsconfig.build.json && pnpm run copy-ansible",
  "copy-ansible": "cp -r ansible dist/ansible"
}

Mocha runs the tests, and the project also carries a Taskfile.yml, a Vagrantfile and flake.nix for a Nix based development environment, so there is more than one way to get the same local setup.

A multi-stage Dockerfile that installs Pulumi and pnpm first

The container image shows how the two toolchains meet. The base stage is a Node image, given as node 25.6.1-trixie-slim through a build argument, with curl, unzip, ssh and python3-pip installed on top of it. pnpm is installed globally with a pinned version, and a separate stage downloads a pinned Pulumi release for either linux-amd64 or linux-arm64 and unpacks it into /usr/local/bin.

ARG NODE_VERSION="25.6.1-trixie-slim"
FROM node:${NODE_VERSION} AS base

The TypeScript is compiled in a dedicated stage so that dev dependencies do not end up in the final image, and the ansible directory is copied in because the packaged node code expects it at runtime. The apt, pnpm and Pulumi layers are all pinned to specific versions, which is the difference between a reproducible image and one that changes underneath you. Two other files at the root of the repository suggest how the project is operated day to day: install.sh and cloudypad.sh sit next to each other, and the release process is managed with release-please, visible in the release-please-config.json and .release-please-manifest.json files.

AGPL-3.0 with a commercial option, and a licence field that disagrees

Licensing here needs a careful read. The README states that Cloudy Pad is licensed under the GNU General Public License v3.0, and that a business-oriented licence is also available on request to the maintainer at [email protected]. The repository has a LICENSE.txt file, and the project's licence field is recorded as AGPL-3.0. There is one inconsistency worth flagging rather than smoothing over: the package.json in the repository declares its license field as ISC, which does not match the AGPL-3.0 described in the README. That may simply be an oversight in a field that npm publishing tooling reads, but for anyone planning to embed the tool in a product, the question of which terms actually apply needs an answer from the maintainer before you rely on it. On the release side, the tags v0.45.0, v0.45.1 and v0.45.2 all landed between April and May 2026, and the version in package.json matches the v0.45.2 tag.

Editorial conclusion

Cloudy Pad fits a player or a small studio that already has cloud accounts, wants a game server for a few hours a week rather than a subscription, and accepts operating the instance itself. It does not fit someone who wants a curated game catalogue with no infrastructure work, and the AGPL-3.0 licence plus the 0.45.2 package.json entry pointing at ISC is a discrepancy to resolve with the maintainer before you build on it. Verify three things first: that your provider account can create the GPU instance type you need, that your client can reach Moonlight through your network, and how the documentation at docs.cloudypad.gg describes the CLI deployment path. The last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. PierreBeucher/cloudypad on GitHub
3. Project website
4. README
5. Releases