Show HN: Pgs.sh – A zero-dependency static site hosting service for hackers (pgs.sh)
I wanted to show a sneak peak of something I've been working on the for the past few months.
I build a lot of projects that involve static hosting and became frustrated by how complicated it is in 2023. All I need to do is move files from my CI onto a server that can serve the files. It shouldn't be as complicated as it is on GCP, AWS, etc. And the ones that are marketed as easy (e.g. Cloudflare Pages, surge.sh) still require the end-user to install a tool first.
With pgs.sh the user doesn't need to install anything. Signup is as simple as SSHing into pgs.sh and creating an account. Creating new static sites is as easy as copying files to pgs.sh.
To go even further, we have added features like instant promotion and rollback to make it easier to manage deployments safely.
The entire service can be managed via SSH commands. Pasted below is our help SSH command: https://erock.pastes.sh/pgs-cmds.md
This service is in closed beta, but if you join our irc channel #pico.sh @ libera.chat we will invite you to test it out.
I'd love to read some feedback on this service, thanks!
41 comments
[ 4.1 ms ] story [ 54.0 ms ] threadUsers create an account by SSH'ing into our server (e.g. `ssh new@pgs.sh`), we record the public-key used to remote into it. Then to use the service you either a) run SSH commands (e.g. `ssh {user}@pgs.sh help`) or copy files to our server (e.g. `scp -r ./public/* {user}@pgs.sh:/my-project`).
Under the hood, we use golang's ssh library to forward files being uploaded to our object storage service, record entries into our postgres database, and then have our web service serve those files.
But currently, our recommendation is to keep your private key that you use to access pico services somewhere you won't lose.
Currently the only way to have multiple public keys is to log into the CMS: `ssh {user}@pgs.sh` and then go to "Manage Keys" and then there's an option to add another public key (press "n").
[0] https://about.gitlab.com/blog/2022/08/17/why-we-have-impleme...
[1] https://gitlab.com/gitlab-org/gitlab-shell
Edit: I love what I see.
This post is really trying to see how interested people are in a service like pgs. If there's demand, we will figure out a way to charge users based on usage (e.g. bandwidth, storage, etc.).
Asking seriously without any intention of being demeaning this looks like a great project, new alternatives are always welcome!
Doesn't git solve all of these issues other than "not creating the project first"?
For example github pages offers version control, custom domains, asset hosting, https, deployment with a similar type of command "git push"?
I've historically used github pages and found it kind of lacking. Many repos will have a completely separate branch for the static site -- which feels awkward and hidden. Further, not every static site needs an associated GH repo, especially for prototyping. There's friction there and doesn't perfectly line up with use cases I've had on previous projects.
For example, I can create an unlimited number of different static sites using a single repo with pgs.sh. Things like monorepos with many static sites are comfortably in our wheelhouse.
Especially when it comes to prototyping, I want something that I can spin up very quickly, without the ceremony of creating a repo, creating a static site project, installing tools, setting up CI, etc. pgs.sh doesn't need any tooling or external services to be fully usable on its own.
For example, I'm building a static site generator for git (https://pgit.pico.sh). When I was prototyping, I didn't want to immediately setup static site hosting through traditional means. I just wanted my prototypes published so I can see how it looked.
The north star here is: what is required to publish a static site? With pgs, it's just an SSH key-pair. Having said all that, ease-of-use with GH Pages is right up there with pgs.sh and I see how we are competing with that excellent service.
> Especially when it comes to prototyping
That makes sense! You're definitely right that github pages does have added friction for mono-repos and also the sporadic projects I have.
I was able to build, "sign up", deploy and view an astro app within about 3 minutes at the time. The only barriers I ran into (me being cute trying to break things) are documented on the link provided (50 MB max file size). I had minimal/no performance issues (even when being cruel) to the backend and it served up assets happily. Routing and updating the app (with updates reflected immediately) worked without any issues for me at the time.
I haven't tried the GHA yet (I was mainly doing it off my local machine), but looks like it'll be a pretty slick end-to-end flow for frontend apps with a simple git push.
Note: I used to work alongside one of the creators of this (and other pico.sh projects) and love seeing their stuff on HN
Disclaimer: I work at Netlify, but not on compliance.
Speaking from experience, I had similar idea for hosting static sites albeit without the ssh model around it.
Ultimately, these files are hosted in our object storage service so it should theoretically be easier to scale out if necessary.
Further, we tried to provide more modern ways to manage projects via promotions and rollbacks, github actions, to make it feel a little more comfortable to devs in 2023.
Once there's a way for people to try out the project, you'd be welcome to post it again.