Cloudron Forum

@fbartels awesome, thank you! Will try this out.

Update: very close!

Using server https://localhost.dwebyvr.org
node:fs:1659
  const stats = binding.stat(
                        ^
Error: ENOENT: no such file or directory, stat '/website/*'
    at Object.statSync (node:fs:1659:25)
    at collectFiles (/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:60:19)
    at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:225:40
    at Array.forEach (<anonymous>)
    at Command.put (/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:221:15)
    at Command.listener [as _actionHandler] (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/lib/command.js:494:17)
    at /usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/lib/command.js:1296:65
    at Command._chainOrCall (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/lib/command.js:1193:12)
    at Command._parseCommand (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/lib/command.js:1296:27)
    at /usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/lib/command.js:1082:27 {
  errno: -2,
  code: 'ENOENT',
  syscall: 'stat',
  path: '/website/*'
}

So somehow have to give it context of the checked out repo I guess?

Here's the file in the repo I'm working with: https://github.com/DWebYVR/localhost_vancouver_webring/blob/main/.github/workflows/surfer.yml

I'd like to auto deploy some code from a Github repo, using Github actions after a commit happens, to copy files to Surfer.

Has anyone documented this?

Yeah this isn’t an integration. It’s using Minionto store files as the backend for an IPFS node.

There is an S3 plugin for IPFS (developers need to compile it in) that could be used with Minio, but as girish said, you’d still need to install IPFS separately.

@rosano woo hoo! Thanks for this not having to learn much of Docker tutorial!

The new thread is for funding packaging and support https://forum.cloudron.io/topic/11178/custom-cloudron-image-for-elasticsearch

I’m no good with Docker, but what I can do is pool funds and rally people to get it done.

@rmdes yes ideally it could be used by other apps.

First goal would be configuration so it works with Mastodon, and I assume config details for other apps could then be contributed.

Not owned by Jack Dorsey (he’s on the board, majority shares owned by Jay Graber thr CEO and the team).

Running your own PDS means the data for your account is stored on it, implementing the open AT Protocol.

+1 for packaging.

I’d like to pool funds to get ElasticSearch packaged to be deployed on Cloudron and set up to integrate with a Cloudron installed Mastodon.

See this for background notes https://forum.cloudron.io/topic/5427/how-to-install-elasticsearch-on-mastodon/40

This adds useful search to your Mastodon instance.

I’m looking for both a developer that wants to be paid to do the work, and people who are interested in contributing some funds.

I can host an OpenCollective or similar to pool funds — I’m also looking to experiment with Polar.sh https://polar.sh

The output would be a git repo with dockerized Elastic Search and necessary Cloudron Manifest, as well as instructions on how to install.

The install could use the Cloudron CLI interface to install remotely.

Separate VPS == means me running an entire other operating system, maintaining it, and updating it. So costs and time. I’m running Cloudron precisely so I don’t have to do this.

It’s totally fine that you only support some apps — but when it includes core functionality for an app this is the sort of thing people are going to want.

Ok, I’ll start a thread about crowdfunding ElasticSearch packaging for a custom Cloudron docker image.

I think the challenge here is that people who can’t package custom docker are blocked from using supported apps with full features.

If Cloudron isn’t going to work on it, would be good to know, so I can figure out how to package it manually.

Is Cloudron going to directly support ElasticSearch installs so Mastodon support can be full featured?

What is the recommended path here that doesn’t mean running a second machine?

@girish

I think git link / image registry link is the most flexible.

Essentially it could run the code that Cloudron CLI runs anyway.

@marcusquinn funny enough, it turns out YOU posted a wishlist item for what @tennox is building -- an IPFS node to be run on Cloudron.

https://gitlab.com/wovin/deploy/ipfs

I made a request in their issue queue https://gitlab.com/wovin/deploy/ipfs/-/issues/2

And funded their open collective https://opencollective.com/wovin/projects/ucan-host-ipfs

IPFS desktop totally works from your desktop. Figuring out how to configure it and connect it with an always on Cloudron node could be a future feature.

And as you mentioned, I'm interested in the DNS mapping too.

You’re not choosing between the AGPL and another license, and yes, with AGPL lets you eg charge for hosting. If you make any changes you are obligated to contribute them.

The core of Cal.com is licensed under AGPL. This changed in September 2021 https://cal.com/blog/changing-to-agplv3-and-introducing-enterprise-edition

They have two commercial license offerings with additional features that are not AGPL. The enterprise license (support, branding, and features for enterprise) and the platform license (fully integrate into your saas offering with full white labeling - their example is a Tele-health platform).

Cloudron installs the AGPL components. And, you can contact Cal.com and pay them for an enterprise license to unlock those features.

@LoudLemur a Penpot install and named projects

@jdaviescoates @robi thanks! Here's the presentation https://assets.cloudron.io/presentations/baylisa-august-2019.pdf for others not clicking through / wanting a written version.

For context: I've been running and creating Heroku buildpacks since they launched 10+ years ago, precisely because buildpacks are simpler than Docker and make things easier for mortals to self host

Now, thinking about a broader "app store", and more hands maintaining common apps, I'm wondering about connecting with other communities to make lighter maintenance work.

Effectively: what is the difference between some-form-of-buildpacks and Cloudron's current packaging format?

@scooke said in Standard package formats:

Do I take this to mean that I can take any apps's buildpack, say from Heroku (or from any of those listed), and just run it in any of those mentioned companies, and it will just work?

Yes. There is a growing list of platforms that support Buildpacks. There are some related efforts like nixpacks growing as well.

eg. here's Digital Ocean list of buildpacks they support https://docs.digitalocean.com/products/app-platform/reference/buildpacks/

Has there been discussion about adopting a packaging format standard rather than a Cloudron specific one?

The one that’s probably closest is the Cloud Native Buildpacks from CNCF https://buildpacks.io/

Why? It means a wider universe of apps that could be ready to go. More information and education on the format.

@LoudLemur _DNSLink is a feature of the IPFS protocol that you map a TXT record of the hash of the root of your published website or app and then CNAME at a single IPFS gateway. This means you don’t need to run a gateway for each domain.

@jdaviescoates not by paying licenses, which is what most aligns with Cloudron’s business model and effort required.

Also, people don’t change their votes. There’s a “decay function”. Maybe I loved AppX when it came out, but want AppY now.

Anyway, this is most interesting to look at over an arc of years, and hopefully Cloudron can continue to be sustainable.