81–90 of 322 posts
Earlier quoted context omitted.
Eek what a hot take. He's talking about the pricing model not the way to operate it. AWS bills for egress data. You can't operate it in any different way to stop that.
Sure about that? So if I have static images going through an ALB to the requesting client, I can't operate in another way to reduce those costs? ... you're sure?
I have 4 apps running on fly.io for most of this year and can recommend them. 2 are elixir apps that have been created on fly, 1 was an elixir app I had running on heroku, and 1 was rails app on heroku I recently migrated. I used their heroku migrator and it worked pretty much automatically. I had a few steps to follow to move the DB, but their docs covered it - https://fly.io/docs/rails/getting-started/migrate-from-…
I can second fly.io, I moved a bunch of personal (but "production") projects from Heroku to it recently (Node, Rust, Rails) and the experience has been great. I can also second their Heroku migrator, worked pretty flawlessly. Overall, my pricing has been about the same or 5-10% less per month. It doesn't have the same "Click this button to add this third-party service to your dynos, with billing included" eco-system…
I get "marketplaces" are hard and there's a chicken/egg problem, but is anyone working on it? I think fly has the rest of it sorted and is clearly better. Would love to see the additional services as well.
The tool requires minimum dependencies inside the kubernetes cluster and it tries to follow all best practices on kubernetes. Unfortunately the tool is not ready yet.
Would something like this be interesting for someone else other than me?
Earlier quoted context omitted.
I can second fly.io, I moved a bunch of personal (but "production") projects from Heroku to it recently (Node, Rust, Rails) and the experience has been great. I can also second their Heroku migrator, worked pretty flawlessly. Overall, my pricing has been about the same or 5-10% less per month. It doesn't have the same "Click this button to add this third-party service to your dynos, with billing included" eco-system…
That's the one thing I haven't seen anywhere else. I think technically, for "run simple automatically built containers with little dev effort." there are many better solutions than heroku. The marketplace is the only existing differentiator for heroku, and I don't really understand why no-one seems to be trying to recreate it. I get "marketplaces" are hard and there's a chicken/egg problem, but is anyone working on i…
I don't think that particular type of marketplace suffers from the chicken/egg problem, as that problem for me indicates when you must acquire two marketplace participants but it's hard to acquire one without the other.
But when it comes to integrations like this, you could easily write your own integrations as long as the platforms you try to integrate have APIs. Or contract freelancers to build those two. You don't need to have the platform owner to write the integration itself.
I guess I'd call it a "soft chicken/egg" problem rather than "hard".
Earlier quoted context omitted.
It's funny how people are different, after using CapRover for years I tried Coolify but it felt like so much functionality was missing that I would not use it over CapRover in its current state. All the things you mentioned (GitHub webhooks, custom domains, SSL certs, reverse proxying) are supported by Cap. It also supports Docker Swarm.
I use CapRover and my main criticism is the non-zero downtime deployment. Also when I update docker some apps don't restart properly, but that may just be my (basic Ubuntu dedicated) server though.
Tangentially I was looking at Render.com the other day and they also don't support zero downtime deployments if you have a mounted volume, so it's not very uncommon even on cloud platforms.
As for restarts, I didn't have that problem yet, I believe CapRover adds `restart: always` to all the running containers so they should automatically boot. You might want to check out the logs of the containers that don't restart or just always hard restart the server after a Docker update.
We are really recommending https://www.clever-cloud.com/ . Their stack is awesome, great uptime and great support.
Very reliable, I've never had a problem with it.
I have 4 apps running on fly.io for most of this year and can recommend them. 2 are elixir apps that have been created on fly, 1 was an elixir app I had running on heroku, and 1 was rails app on heroku I recently migrated. I used their heroku migrator and it worked pretty much automatically. I had a few steps to follow to move the DB, but their docs covered it - https://fly.io/docs/rails/getting-started/migrate-from-…
Most definitely. For most parts, it is hashicorp-as-a-service but without hashicorp!
Earlier quoted context omitted.
AWS is IaaS not PaaS. With IaaS you need to hire competent infra admins. PaaS abstracts away much of that requirement.
https://aws.amazon.com/apprunner/ https://aws.amazon.com/lambda/ https://aws.amazon.com/fargate/ https://aws.amazon.com/appsync/ https://aws.amazon.com/elasticbeanstalk/
Whereas, Lambda / Lambda@Edge / CloudFront Functions are of course wayyyyy more expensive (even if more capable) than workers.dev.
Earlier quoted context omitted.
It's funny how people are different, after using CapRover for years I tried Coolify but it felt like so much functionality was missing that I would not use it over CapRover in its current state. All the things you mentioned (GitHub webhooks, custom domains, SSL certs, reverse proxying) are supported by Cap. It also supports Docker Swarm.
Hey, the founder of Coolify here. I'm constantly adding new features to Coolify. Which ones are you missing (except Docker Swarm)?
Also I think the way you create different kinds of resources are confusing in Coolify, like what is a "Git Source" or "Destination", all I want is to run my container. It's very different from Herokus/Caps interface and not in a good way.
Also why can't I just deploy from an image? In CapRover I often spin up a container, like `redis-commander` or `wordpress` and then just configure its env vars and volume mounts. In Coolify it seems you have to connect a GitHub repo which is not a desirable workflow for me.
Earlier quoted context omitted.
It's funny how people are different, after using CapRover for years I tried Coolify but it felt like so much functionality was missing that I would not use it over CapRover in its current state. All the things you mentioned (GitHub webhooks, custom domains, SSL certs, reverse proxying) are supported by Cap. It also supports Docker Swarm.
When I looked at CapRover recently, the GitHub integration in the docs required manually setting up a GitHub Actions integration and I couldn't exactly figure out what parts I needed to change since the example was for a NodeJS app, and I'm assuming it needed to be added or changed for each repo you want to track git pushes from. In contrast, with Coolify, you simply login with your GitHub account and it installs a (…
You can also use the built-in webhook from inside CapRover control panel but it requires you to log in via your GitHub account in Cap (I created a secondary CI account for this).
Installing a GitHub app comes with challenges, it basically gives Coolify access to your account should they want it, since they control the app and not you. This is bad from a privacy perspective.
CapRover has dark mode. :-) But yes the design is more utilitarian in Cap and not as nice to look at.