1,059 karma · joined November 1, 2017
We recently added serverless functions for backend support, specifically for the bhvr[1] stack though they work with just about anything.
[0] https://orbiter.host [1] https://bhvr.dev
Orbiter started as static website and web app hosting, but we recently added what we call server functions (what you call serverless functions). So now you can build full stack apps. Our preferred development stack to support is the new bhvr[2] stack.
My co-worker and I started this as a side project because we were building so many sample apps, proofs of concept, and engineering as marketing apps and we were feeling more and more locked into Vercel every day. So we wanted to go back to client and server separation and when we did that, we realized most hosting providers have moved toward server-side rendering as the default.
Client-side rendering isn’t for everyone, but plenty of people still make simple websites or even complex CSR web apps and don’t want to deal with fully integrated solutions like Vercel (and Netlify now to a lesser extent). Plus they want the flexibility of choosing different tools for their frontend and backend.
This remains a fully bootstrapped side project for us, but it’s gotten the most traction of any side project either of us has worked on.
Disclaimer, I wrote this for work but it is based on ideas I developed outside of work. https://pinata.cloud/blog/will-json-work-as-a-database/
My co-founder and I launched Orbiter in January to solve an issue we were having with all the mini sites and apps we were launching for our day job. We had gotten frustrated with complicated deployment pipelines and wanted to return to launching simple static sites and launching them quickly.
So, we built Orbiter. We focused initially on making uploads of your static build folder simple and fast. We then layered in a CLI, an API, and a Github action. So Orbiter can fit into just about any workflow.
From the beginning, we wanted it to be open source, and after about 2 months of work, we have just open sourced the entire stack[1].
I hope you'll give it a try and please drop any feedback here.
Recently open sourced everything.
Though on the 1GB total storage I have a question: with a maximum of 2 sites on the free plan, what scenarios do you see your sites being larger than 1GB? I’m genuinely curious if we’re overlooking something.
The app is built with only two dependencies: Clerk for authentication (but there's a guest mode specifically for the HN crowd to play around with) and Pinata for file storage and retrieval. I kind of thought I could speed run this in a day, and I was mostly right. I ended up getting the first version done in 2 days. I've polished it up a bit, and now it's ready to play with.
Would love to hear any feedback!
Edit - this is designed for desktop only because the old Macintosh operating systems were not mobile.
I give some specific examples in this blog post I wrote late last year: https://www.polluterofminds.com/thinking-in-public/
I think of IPFS as being an open data platform first. You can connect to it and disconnect as frequently as you like. The underlying p2p capabilities don't have to necessarily be fast. It just has to do the job it was designed to do—get content in a permissionless fashion.
Speed, convenience, reliability, and more are not the problems protocol need to solve for. Providers can solve for these problems without infringing on your ability to "take your ball and go home." Take Pinata for example. We provide dedicated IPFS gateways that provide essentially the same experience you would expect from traditional cloud providers. But if you ever want to leave Pinata or back your data up or just inspect your data, you don't need Pinata's permission. IPFS media is public and open. Convenience is a layer on top of that.
IPFS also doesn't need or have tokens. Filecoin is a separate entity. IPFS is especially powerful because it is not linked to a specific blockchain or currency.
Full disclosure, this app was built under the Pinata (https://pinata.cloud) banner, but being able to bring it to life during a hackathon was an incredible experience. The idea stemmed from the original release of a feature Pinata calls Submarine. We rolled this feature out last year, and it let people upload media to private storage nodes, generate IPFS content identifiers for verifiability, and share that content with a selective audience. The problem was that individuals and communities wanted to have more complex mechanisms and automation for sharing the media. They didn’t want to have to manually generate a link to the content.
For developers, this was no problem. They could write code and implement their own solutions to programmatically generate access tokens for the locked content based on the criteria they set. For non-technical creators, this was a non-starter. We believe submarine.me solves that.
Creators simply have to choose how they’d like their media to be unlocked (currently submarine.me only supports NFT unlocking, but more mechanisms will be rolling out soon), provide preview data about the locked media, then upload the media that should be private. When they do so, a simple link is generated. These creators can then safely share that link on Twitter, Discord, Telegram, or anywhere else they want, knowing that unauthorized people will not be able to unlock the content.
For those that are trying to retrieve the media, the experience is dead simple. Go to the link, sign a message verifying control of the Ethereum wallet that holds the NFT, and if they do, in fact, have the NFT in their wallet, the private media is returned. If they don’t have the NFT, they are blocked.
Here is a demo video of submarine.me in action: https://www.youtube.com/watch?v=YhT4Xqn1tYI
I know the Hacker News community prefers to be able to experiment with apps on Show HN without having to sign in or subscribe, but this app is directly linked to existing Pinata accounts. So to use it, you will have to have a Pinata Professional Plan account.
Looking forward to hearing everyone’s thoughts!