Running an IPFS node on a virtual private server is an operations decision, not just an installation exercise. A server that starts Kubo successfully may still have an exposed administrative interface, inadequate storage, no recovery procedure, or a gateway that serves a different purpose from the one you intended. A useful setup begins with the service you want to operate and the risks you are prepared to manage.
This checklist is intended for publishers who understand basic server administration and want to retain their own website releases. It does not assume that one machine is sufficient for every traffic pattern. It also does not present the VPS as a substitute for independent copies or a tested delivery plan. The IPFS VPS overview summarizes the architecture before you begin.
Define the node's job
Decide whether the node is primarily a content provider, a gateway for your own site, an administrative publishing endpoint, or a combination. These roles have different exposure and resource requirements. A server that retains a few approved releases does not need to become an unrestricted public retrieval service by accident.
Write down what must be reachable from outside the machine and why. Include peer connectivity, the public HTTPS endpoint where applicable, and the private administration route. Keep the list small enough that you can explain each exposed interface.
Also define the failure tolerance. If the VPS disappears, what should visitors still be able to retrieve, from where, and who will restore the service? Answering that question first prevents a single-node setup from acquiring an unearned reputation for redundancy.
Protect the administrative boundary
Kubo's RPC interface controls the node. It is not the public website gateway. The official Kubo RPC reference warns that the API provides administrative access and should not be exposed casually to the public internet. Keep administration private by default, using an appropriate secured access method for your operating environment.
Do not copy a broad bind address into production merely to make a remote tool connect. Review firewall rules, proxy behavior, and authentication as a complete path. A service bound to a loopback address can still be exposed through an incorrectly configured reverse proxy or container mapping.
If you need remote automation, design a narrowly scoped access path and protect its credentials. Never place administrative tokens in the website's HTML, JavaScript, or public deployment files.
Plan storage around actual retention
Estimate the size of the current release, the number of versions you intend to preserve, and the operational headroom required by the node. Then measure growth after deployment. A planning estimate is a starting point, not a promise that disk usage will remain fixed.
Keep a manifest of retained root CIDs and the reason each release remains pinned. Separate active releases, rollback candidates, and long-term archives. This makes maintenance decisions clearer than a repository full of unexplained historical data.
Set alerts before storage is exhausted. Decide who receives them and what action is appropriate. An alert that reaches an abandoned inbox is not a monitoring plan. Document the maintenance window and the procedure for expanding storage or moving the repository when needed.
Install with an upgrade path
Use a supported installation method and record the version you deploy. Keep operating-system packages and service configuration understandable to the next administrator. Avoid a collection of one-off shell commands that cannot be reproduced or reviewed later.
Before upgrading, read the release information relevant to your current and target versions. Test against a nonproduction environment when practical, and preserve the data and configuration required by your recovery plan. Do not assume that replacing a binary is the only step a future release will require.
Run the process under an appropriate service account rather than granting it broad privileges without a reason. Ensure that service restarts, logs, and resource limits are managed consistently with the rest of your server environment.
Publish a gateway deliberately
A public gateway is a delivery service with its own traffic and security considerations. If the goal is to serve your own website, review whether the gateway should retrieve arbitrary content or only serve the content you intend to provide. An unrestricted configuration can create an operational role you never budgeted for.
Keep TLS termination and hostname routing explicit. Test the final public hostname, not only a local port on the server. Verify that the proxy forwards the information needed by your chosen gateway configuration and does not accidentally route requests to the administrative API.
Use our DNSLink and custom-domain guide to connect the delivery route to a release. Adding a naming record should be a controlled publishing step, not a substitute for gateway setup.
Separate liveness from useful availability
A running process is a liveness signal. A successful retrieval of the intended release is an availability signal. Monitor both. A daemon can be healthy while a particular website's content is missing, and a cached homepage can appear healthy while fresh retrieval is failing.
Choose a few meaningful checks: retrieve the root document, a nested page, and an essential asset; confirm an expected release marker; and record response failures with enough detail to identify the layer. Run at least some checks outside the server's own network context.
Avoid making strong uptime claims from a single probe. Use the results to trigger investigation and improve the runbook. Distinguish DNS errors, TLS failures, gateway errors, missing content, and frontend mistakes in your incident notes.
Make pinning part of deployment
A release process should not stop when the files have been added. Record the root CID, confirm retention, and test retrieval before updating the public name. Keep the previous release available until the new one has passed its rollout checks.
A pin manifest is useful only when it matches the content the node can actually serve. Periodically verify representative releases, especially after maintenance, migration, or storage changes. Do not assume a historical deployment log proves that the necessary data is still present.
For a comparison of operating your own node and using managed retention, read IPFS hosting, pinning, and cost planning. The choice is about responsibilities as much as infrastructure.
Back up what recovery needs
A backup plan should identify the source project, approved build artifacts, pin manifest, configuration, and any sensitive identity material required by your setup. Protect private material separately from public content. Decide who may access it and how access is recovered when an administrator is unavailable.
Practice restoration rather than checking only that an archive file exists. Bring a replacement environment up, recover a known release, and verify it through the intended delivery route. Record the missing steps while the exercise is still fresh.
Keep independent copies where the consequence of losing the VPS justifies them. Two copies on the same machine do not protect against losing that machine. Likewise, a second provider should not depend entirely on credentials stored only on the original server.
Prepare a small incident runbook
Write a short response sequence for the failures most likely to interrupt your publishing workflow. Include disk exhaustion, unavailable content, a broken domain mapping, and suspected credential exposure. Record who can change the public pointer and who can restore the previous release.
Use concrete checks and expected outcomes, not instructions such as restart everything. A restart can hide evidence or leave the real cause unresolved. Preserve useful logs without retaining secrets or unnecessary visitor information.
Update the runbook
After an incident, update the runbook and tests with what you learned. The aim is a setup that becomes easier to operate, not a growing collection of undocumented emergency fixes.
Conclusion: operate the release path, not just the process
A dependable IPFS VPS setup has clear interfaces, controlled administration, known retained releases, meaningful monitoring, and a practiced recovery path. The daemon is only one component. Start with a narrow role, test what a visitor actually receives, and keep deployment records outside the machine that serves the site. That discipline matters more than treating a successful installation as the end of the job.
