Closed betas can't be Show HNs. Please see https://news.ycombinator.com/showhn.html.

Once there's a way for people to try out the project, you'd be welcome to post it again.

Oh shoot! Totally misread the showhn requirements, my bad!

Just a warning - once you open this up you will need to be really good at handling takedowns. You will get abuse, probably quickly. This will mostly be phishing or malware sites, but there may also be CSAM.

Disclaimer: I work at Netlify, but not on compliance.

Great point, thanks for the heads up! It is definitely a big reason why this is closed beta atm.

I would say before you get a takedown request such platform is infested with malware and e.g. Google blocks the website so any attempt to visit it results in big red warning.

Speaking from experience, I had similar idea for hosting static sites albeit without the ssh model around it.

pastebin owner has been very transparent over the year to these challenges but it's hard today to find links back to his experiences, but they are out there and will give a clear idea of what to expect.

Does rsync work instead of scp to take advantage of incremental updates?

We have rsync implemented with our other pico services, but we need to spend some time to finish implementing the rest of the protocol (support proper diff/upload, this includes recursive file uploads). We'll have that implemented once we're ready to open this up to everyone else. Of course, contributions to help get it over the line are always appreciated :)

Is this different from and old-school hosting provider that has SSH and SFTP access?

Great question! It's going to feel very similar but under-the-hood we do not store any files on our SSH service's VM. We use golang's crypto/ssh library to intercept any files being uploaded and instead send them to our object storage service (minio atm).

I haven’t dug in too deep yet, but I wanted to say that I love this concept!

I appreciate it! Let me know if you have any questions!

I created an account and if I do `ssh <name>@pgs.sh help` then I get `you do not have access to this service`?

Currently it is in closed beta. If you want to get an invite, join our IRC channel #pico.sh @ libera.chat and we will send you an invite.

I love the pico.sh ecosystem. I'm using lists most, but will probably using this a lot!

I love the concept and the services you've built around it, great work!

creating a new project by just SSH'ing in seems interesting but.. like.. what's the security model for such a thing? Do other platforms do this? ...asking for a friend :)

GitHub and GitLab both do this. They only give you enough of a shell for Git commands. I'm not sure how GitHub's is implemented, but GitLab's used to be a locked down Unix shell (i.e. in theory only the commands needed for Git would be accessible, with the caveat that there could be bugs) and now [0] it is a Go program [1] that listens for SSH connections and implements an in-process shell that only supports Git commands. Fun fact: you can create a GitLab PAT with an SSH command. (Another useful trick, to verify your SSH keys are configured properly for Git, is to run `ssh -T git@github.com` which will print a welcome message including your username.)

[0] https://about.gitlab.com/blog/2022/08/17/why-we-have-impleme...

[1] https://gitlab.com/gitlab-org/gitlab-shell

The most important thing to know here is authentication and authorization is based on public-key cryptography (via SSH).

Users 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.

how does one add a public key from a second box? does ssh-copy-id work?

That's actually a really great idea that we hadn't considered, thanks!

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").

does that mean I (or you?) can never recover my account if I lose my private key?

Great question! That's correct. We do help people recover lost accounts when requested which typically involves some proof they owned the account. At the top of the feature backlog we plan on adding recovery codes so a user can access their account when they lose their private key.

But currently, our recommendation is to keep your private key that you use to access pico services somewhere you won't lose.

How are you going to be able to make money off this?

Edit: I love what I see.

Right now, we are able to provide all pico services for free. Most of them have been running for a year+ without much need to charge.

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.).

That's really cool. What is pic.sh's funding plan?

Love this, thank you!

Very cool.

Absolutely. There were a couple moments where questions like "isn't this just sftp?" coming up in my mind.

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.

Some folks cannot afford hosting, including the time to set it up. Until recently*, it was pretty difficult to find providers who would take monero, as well. User-anonymizing, free hosting of static content has some moral value to it.

Is it open source?

Yes! We have a monorepo with a bunch of services, but it's all here: https://github.com/picosh/pico

Lovely! Thank you so much

Sweet, I've been waiting for this announcement for some time now, as it's been pretty easy to use.

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

This looks cool!

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 think you make a very valid point, so thanks for raising it. This isn't the first time today I've received this feedback.

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.

> Things like monorepos with many static sites are comfortably in our wheelhouse.

> 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.