puter icon indicating copy to clipboard operation
puter copied to clipboard

How can we make hosting Puter easier?

Open KernelDeimos opened this issue 9 months ago • 7 comments

I'm looking for any and all suggestions. Many people still struggle with running their own instances of Puter. Whether its documentation changes, tooling, anything; we've put a lot of effort toward making Puter easy to setup but it seems more advice and contribution from others is the only way we can get this where we want it.

Note: Anything comments related to setup within Puter itself immediately after initial deployment should go to issue #1125 instead.

KernelDeimos avatar Mar 01 '25 20:03 KernelDeimos

Documentation; for example, doc/self-hosters/first-run-issues.md could use benefit from additional scenarios.

p00pcvm avatar Mar 09 '25 07:03 p00pcvm

I would really love to see in depth documentation about hosting Puter with a reverse proxy (nginx proxy manager preferably). I didn't have trouble setting it up on LAN and accessing it, but trying to reverse proxy it has been a pain for some reason.

onelocked avatar Mar 09 '25 08:03 onelocked

Documentation; for example, doc/self-hosters/first-run-issues.md could use benefit from additional scenarios.

Still trying to setup Puter for the first time via Docker container on a home server, running into these issues for the last few days:

  • Domain configuration is not working
  • Host configuration is not working
  • "allow_nipio_domains": true seemingly not working
    • Making changes to the above based on previous issues results in the same message: Invalid Host Header
    • When I say "X configuration is not working", I mean that I have followed the instructions in the documentation and read through issues opened by others

I admit that I am a novice and these could all be my fault, but wanted to share my experience.

p00pcvm avatar Mar 11 '25 19:03 p00pcvm

We could provide a script that can be run through the CLI, which would basically host an instance successfully by performing recursive checks for errors.

Here's how the flow might be:

  • The script is called through the CLI

  • It checks and caches or stores the host machine network configurations and other details ( only necessary details )

  • Starts a recursive loop of building the project until a successful instance is hosted

    • It detects any errors throughout this process by accessing the logs, and retries after changing the config/ other files eg. port details.
  • Once an instance is successfully hosted, the recursive loop ends and the user is alerted. They can then investigate the modified configs and/or logs from the script.

sashpawar11 avatar Mar 13 '25 04:03 sashpawar11

@p00pcvm - any additional information you can provide about the things that aren't working would be helpful. For example with nip.io domains, you should only get the "invalid host header" error if you're not accessing puter through the corresponding <ip address>.nio.io domain.

@sashpawar11 - this is an interesting idea but I see a lot of very complex logistics in implementing such a thing. First is how do we test for a successfully hosted instance? This script would need to try to access the server from outside of the server, but presumably it's running on the server. Also, how would it decide what configuration changes to make? We could use AI but then deployment is non-deterministic and requires API keys or free service that may be subject to restrictions on IP address ranges belonging to hosting providers.

KernelDeimos avatar Mar 13 '25 04:03 KernelDeimos

First time making a suggestion, so this might seem redundant, but what if you tried autobuilding a docker container as soon as you try to run it normally?

i hope this is a good idea.....

RandomizedAlias avatar Apr 11 '25 13:04 RandomizedAlias

It would help if in the setup guide would be a script or a command list for standard debian environment ( blank minimal setup ), 1: setup the right npm, 2: setup nginx with correct settings, 3: clone the puter repo and build it correctly, 4: setup the correct CORS settings, 5: full base config ( volatile/config/.... ) that would be really great. I did spend hours now to set it up. now it runs but still websockets errors in the browser console.

universemodifier avatar Apr 23 '25 10:04 universemodifier

Since it's such a ubiquitous technology, also used as the back-end on many platforms that allow plugins/apps etc, getting it to launch properly on docker, with a compose file, would be top priority. Also since it "should" be pretty platform agnostic. I spent at least an hour just getting the container to launch properly and give me a login screen, mostly by searching through issues on here.

pieterdevriesch avatar May 26 '25 14:05 pieterdevriesch

Since it's such a ubiquitous technology, also used as the back-end on many platforms that allow plugins/apps etc, getting it to launch properly on docker, with a compose file, would be top priority. Also since it "should" be pretty platform agnostic. I spent at least an hour just getting the container to launch properly and give me a login screen, mostly by searching through issues on here.

sorry for two week delay, but maybe you can ask someone from https://github.com/dockur ? they use an autobuild in their windows and macOS repos

RandomizedAlias avatar Jun 10 '25 20:06 RandomizedAlias

Hi everyone

Firstly, thank you for all the incredible work on Puter. It's a really promising project, and I’m excited about where it’s headed!

While setting up my own instance recently, I ran into some friction points that I think others here have also mentioned:

The Invalid Host Header issue even with allow_nipio_domains: true enabled

Lack of clarity around reverse proxy setups (especially for nginx proxy manager users)

Needing more complete examples of Docker Compose + env configuration

Confusion between what’s expected immediately post-deployment vs later configuration (issue #1125 helped, but maybe needs a more prominent pointer in the main setup docs)

I’d love to help where I can — maybe we can collaboratively expand the self-hosters docs with community-tested setups (Debian, Docker, reverse proxy, etc.)?

Also +1 to @sashpawar11 's idea of a setup validation script — even a basic CLI checklist or preflight script that logs what passed/failed in the setup would be a great first step and super helpful for debugging initial setups.

Looking forward to contributing

Ishan-Parnami avatar Jun 12 '25 18:06 Ishan-Parnami