We used to host our sites on Netlify, but our eyes fill with glitter when we hear open source and self-hosted. So, we built Meli, which essentially is a Netlify alternative that lets you deploy static sites and frontend applications with ease, featuring per-branch deployments, web/slack/mattermost/email hooks, an API, and a way to manage organizations, teams and sites easily.
We built Meli on top of Caddy, a very powerful HTTP server (https://github.com/caddyserver/caddy). We've used Typescript, Node (backend), React (frontend) and MongoDB for the database.
Nice project! It would be nice if there were some issues that volunteers can pick up to work on. What's the best way to reach the team to discuss this? I'd like to contribute.
Hi there ! So sorry for the delay ! You can reach us at info@charlie-bravo.be ! Thanks so much for offering your help, I'll add some issues so people can pick them up and help.
Hey, great project! However, it is not really open source [0]. Do you mind updating your message and also on Github's README? The correct term would be 'source available'
Looks great! How does it handle DNS? One of the things I like Netlify is not having to deal with the DNS headache. Add some magic strings to the DNS record and Netlify handles the rest.
Just FYI in case you care about this sort of stuff, there's a major eBay-like company in South America called MercadoLibre, that is commonly referred to as MeLi or simply Meli as well, and that also has the $MELI stock ticker. It's not a big deal at all but thought you'd like to know about it as it may impact organic discovery or cause a bit of confusion down the line.
This is interesting; I use Netlify for a Gatsby/Contentful website, as well as for a Netlify CMS one. I don't pay for any of it, so it's hard find a reason to move away. What are some of the problems you've seen people have with Netlify? Other than not being in control of the infrastructure of course.
I found the Netlify CLI pretty exasperating to use. In addition to it just being straight up information overload at any given step, the feedback it does print out is often misleading or the opposite of helpful in some other way. More from my notes on that day:
> My use case is to deploy a static site. I have a directory containing the pages. I've installed the Netlify CLI (itself a stupidly fiddly process). [And I've read the docs by now.] I should be able to init and deploy, trivially, right?
Wrong. Without even trying I ran into some crash bugs in the CLI, for what seems to be a bog-standard use case. On a hunch, I decided to check what would happen if I moved the .git subdirectory somewhere else and re-ran. And whaddaya know, I found that it worked reliably when there was no .git subdirectory anywhere to be found, and it reliably failed when it was present. So even though the contents of .git/ are completely irrelevant for the use case, the CLI is evidently both (a) trying to do something with it, and (b) making some bold assumptions about what's in there and failing hard. My money is on "Nobody at Netlify is even testing this."
(FWIW, no I didn't report this. The overall "feel" of their stuff leads me to believe it would be a painful experience with no upside. Several years ago, I interacted with some Netlify folks early after their launch to give some feedback that was more of the sort "I'm reaching out to inform you of a problem for your own benefit and help you resolve it" than it was anything like "I'm here to get you to help me with my problem". The overall tone of the responses were pretty obnoxious under those circumstances, so I noped out and never gave them any serious consideration until this year, where I discovered the situation above. I have to say it pretty much validated my early opinion.)
sorry to hear about your prior experience. fwiw the CLI was not fully staffed for a long time - but as of last year at least 2 engs are working on it fulltime and they should have capacity to look into your usecase if serious enough.
yes, the CLI looks into .git, no i'm not sure if it was needed for what you were trying to do, but also no i have never run into the issue you describe as an almost-daily user of netlify for 4 years
> I have several free sites on Netlify and none of them seem slow at all - all three sites load in under 450ms on Chrome.
Does this also measure the time to connect to the server? Not sure if Chrome is perfectly correct. I used https://tools.pingdom.com
I'm German. My free Netlify sites load twice as slow from Germany than from the US. US: 1.2s, Germany ~2.5s (and I thought Netlify has servers all around the world?!)
But still, 1.2s is very slow imho. My website on a dedicated VPS, hosted in Germany, loads in 1.2s from the US and 200ms from Germany. The connection time being the slowest part of all. All websites are static and rather small.
Maybe it's unfair to compare the free Netlify server to a paid dedicated VPS, but since this thread is about "self-hosting" vs "using Netlify", I just pointed out that Netlify is slower in my case.
I do something just like this but using CapRover self-hosted PaaS (receives webhooks from git and redeploys automatically) and a two stage Dockerfile: one for my build (jekyll) and another that's just FROM nginx that copies the _site directory to /var/html or wherever nginx serves statics from by default.
Works a charm. Glad to see more work in the space.
I have been wanting to run a Jekyll site on my CapRover deployment, but wasn’t sure the best way to set that up. Do you have a repo that you can point me to to see how you have it setup?
That's how I used to host my static sites but then I switched to Netlify because the UX for me as developer was just so much nicer.
Maybe there's a way to also setup git sync with S3 buckets, but with netlify this is the default. And it's just so comfy to deploy with every git push.
Also using any of the other netlify add-ons (forms, cloud functions) is super quick and simple. Something that I (admittedly an ops noob) can't say about AWS.
You might describe the product directly for those who don't know what netlify is (seems like some kind of combination of a static file server and rsync aimed at enterprise).
It makes me a little concerned that there are so many features.
Depends on what your needs are. For example if you are working on a team, Vercel* automatically deploying feature branches is extremely useful. Pushing a new blog post to your personal site? FTP is probably fine.
Not sure how many times I was on the phone with a client who wanted a few quick updates. I just edited the repo on github, checked it in and BOOM! Told the client the changes were live while we were still on the phone.
That kind of ease of use does wonders for your customer service numbers.
You're comparing a protocol to a set of automation tools. It may or may not be an upgrade. If you want something to handle builds, SSL, routing rules, etc ... then yes.
I've not found in docs anything related to static site configuration files (like netlify.toml or vercel.yml in hosted services). How to configure particular site?
Yup, that's what I was going to say. Separation of concerns is the key here. There's no way in a billion years we could do a better job at this than Cloudflare.
We used to host our sites on Netlify, but our eyes fill with glitter when we hear open source and self-hosted. So, we built Meli, which essentially is a Netlify alternative that lets you deploy static sites and frontend applications with ease, featuring per-branch deployments, web/slack/mattermost/email hooks, an API, and a way to manage organizations, teams and sites easily.
We built Meli on top of Caddy, a very powerful HTTP server (https://github.com/caddyserver/caddy). We've used Typescript, Node (backend), React (frontend) and MongoDB for the database.
It's a beta, but you can install super easily with Docker Compose: https://docs.meli.sh/get-started/installation
Check us out at https://github.com/getmeli/meli !
Looking forward for your feedback :)