[HN Gopher] Flightcontrol: A PaaS that deploys to your AWS account
___________________________________________________________________
Flightcontrol: A PaaS that deploys to your AWS account
Author : handfuloflight
Score : 155 points
Date : 2025-10-06 07:07 UTC (15 hours ago)
(HTM) web link (www.flightcontrol.dev)
(TXT) w3m dump (www.flightcontrol.dev)
| crazycheesu wrote:
| So this is basically a webgui for the aws cli ?
| vends wrote:
| Looks like it offers a much higher level of abstraction than
| that.
|
| Seems closer to Heroku/Vercel but running in your own AWS
| account.
| _joel wrote:
| So AWS Beanstalk? :)
| fhd2 wrote:
| You forgot the trigger warning :)
|
| But jokes aside, I use Beanstalk quite a bit and it's
| mighty leaky, don't find it all that comparable to stuff
| like fly.io, although in spirit it's the same thing I
| suppose.
| holografix wrote:
| So it's a neo-Heroku?
| cmdtab wrote:
| I tried flight control but it was a bit buggy and rough. My
| docker image worked differently on their platform compared to
| other PAAS.
|
| Lot of issues with slow AWS provision or missing APIs on AWS side
| so it would take hours to delete resources created by them.
| flybayer wrote:
| When did you try it?
| kolanos wrote:
| Found this in their roadmap [0]:
|
| > Managed ECS-EC2 clusters in preview
|
| > AWS has a long standing issue with the ECS agent randomly
| disconnecting, resulting in orphaned EC2 instances which can
| cause traffic or deployment degradation.
|
| > We have attempted to solve this a few ways in the past, but
| there were still critical edge cases falling through.
|
| > So we bit the bullet, and developed a robust, full featured
| ECS cluster management solution to solve this problem once and
| for all.
|
| > It's currently in private preview. To get early access before
| we roll it out to everyone, contact support.
|
| I found elsewhere in the Flight control docs where they
| recommend ECs+EC2. While I'm not surprised to hear about issues
| with ECS+EC2, given the reported issues above I don't know if
| I'd recommend it in my docs. Fargate is a far better option for
| most use cases, at least in my experience. Unless you need
| specialized instance types, like GPU workloads.
|
| [0]: https://roadmap.flightcontrol.dev/changelog
| arpinum wrote:
| This could have been some custom cdk constructs. Then at least
| you can plug in SQS / SNS / DynamoDB / CW / IAM all in one
| solution. Flightcontrol doesn't seem to offer these.
| catlifeonmars wrote:
| I've been getting great mileage out of service catalog
| products. They're a great middle ground between custom CDK and
| in-house PaaS. You can even use them as CloudFormation
| resources so they compose well and users are agnostic to which
| CDK language (or Terraform even!) that is used to write them.
| I'm currently experimenting with using them to expose terraform
| modules as CDK constructs.
| coredog64 wrote:
| Service Catalog is on my top 5 list of terrible AWS developer
| experiences, and I've used practically every mainstream
| service.
| catlifeonmars wrote:
| Oh interesting, what was your experience with it, out of
| curiosity?
|
| For my part, there was some initial friction making it
| usable from the publisher perspective but haven't really
| had issues using it from the consumer side.
| tuananh wrote:
| i remember deis, it was amazing self-hosted heroku. too bad they
| were bought by microsoft.
|
| and then there's also flynn.
| bilekas wrote:
| > Your team gets bogged down with complex Terraform scripts,
| manual configuration, and endless CI/CD pipelines.
|
| I really hate marketing speak like this. Terraform is there
| specifically to solve the Aws infrastructure complexity.you
| create your system once and minor changes if needed.
|
| > Flightcontrol fully automates infrastructure provisioning,
| CI/CD, and deployments. All within your own AWS account where you
| retain full visibility and control
|
| Why does everyone think this is a desirable thing? Excluding
| adding to your aws price, you're now vendor locked in for your
| pipelines also.
|
| I'm not seeing any benefits here for any already established
| company, maybe a small start-up of fresh graduates who don't want
| to learn Iac/DevOps ?
| MrBuddyCasino wrote:
| > _Terraform is there specifically to solve the Aws
| infrastructure complexity._
|
| I don't know if anyone here remembers the Ant build system, but
| writing your own Terraform spaghetti strongly resembles the
| days of Ant, before Maven came along. Teams over-engineering
| their build pipeline, building "platforms" that other teams
| must use, an unmaintainable and untestable mess. Time better
| spent elsewhere.
| Y-bar wrote:
| > Teams over-engineering their build pipeline, building
| "platforms" that other teams must use, an unmaintainable and
| untestable mess. Time better spent elsewhere.
|
| This hits home so much!
|
| I remember last year when I asked our Cloud Ops to add an
| additional EC2 instance and adjust sizes on two others. It
| took twelve work hours and resulted in +3k -2k changed lines
| "because they had no way of doing it now without merging
| seven hundred other changes.
| MrBuddyCasino wrote:
| Its an anti-pattern that negates some of the advantages of
| the cloud and re-introduces issues people had when things
| were still handled by the old internal IT infra department.
| I've seen it a lot.
| darkwater wrote:
| That smells like some really nasty problem in your company.
| If the change was really what you said it was, it might
| take some time and terraform code (i.e. nested submodules
| with hardcoded values that needs to support parameters all
| the way down) but it should not be a diff of that size.
| esafak wrote:
| Do you know what they did wrong? I would have made a stink
| about this.
| bilekas wrote:
| > Teams over-engineering their build pipeline, building
| "platforms" that other teams must use, an unmaintainable and
| untestable mess. Time better spent elsewhere.
|
| I have to disagree a little here, if you're already in AWS,
| then an investment in fixing your terraform structure is not
| just worth the money, but gives you a better understanding of
| the infrastructure architecture, you also retain ownership of
| your deployments. What happens if Flightcontrol go down for
| whatever reason? Or are sold off like other's we've seen, or
| god forbid you need some fine tuning that isn't in the
| Flightcontrol's website. You're now depending on, and maybe
| even paying for, an external company for devops support to do
| something you already know how to do.
|
| It seems to be in the long term, that time is definitely not
| better spent elsewhere.
| MrBuddyCasino wrote:
| > _What happens if Flightcontrol go down for whatever
| reason? Or are sold off like other 's we've seen, or god
| forbid you need some fine tuning that isn't in the
| Flightcontrol's website._
|
| These are all valid points. This is a fundamental issue
| with relying on non-open 3rd party solutions and (leaky)
| abstractions. The best solution here would be some standard
| that the hyperscalers implement themselves, but this is of
| course incredibly unlikely.
| Esophagus4 wrote:
| > the hyperscalers implement themselves
|
| I wouldn't be surprised to see that at some point if
| these tools catch on.
|
| AWS in particular has a pattern of bringing toys everyone
| loves in house and making managed services out of them.
| Taikonerd wrote:
| > _some standard that the hyperscalers implement
| themselves_
|
| I'm kind of amazed that they haven't already. It would be
| such a good selling point for Azure, or GCP, etc. "We
| have a UI like Heroku or Vercel. Compare that to our
| confusing competitors!"
| CuriouslyC wrote:
| There are two devops patterns that WORK:
|
| 1. All centrally managed. Engineers hand off repos and devops
| own the instantiation. Devop is a core team with an infra
| monorepo.
|
| 2. Devops capable engineers are embedded into teams, and each
| project owns its own infrastructure with golden path
| guidance.
|
| The hybrid version, central management of most stuff with
| project specific devops burden, is the worst of both and
| causes no end of problems.
| throwaway61352 wrote:
| I guess in an ideal world, a service like this would be a
| layer on top of Terraform. Changes in the admin page would be
| applied using Terraform, and update the config in your own
| Git repository. I think this would be much easier to sell,
| even if they choose to make it "write only" to avoid
| potential complexity of managing user defined configs.
|
| They could get customers initially by promising a simple
| start to get "on the cloud", but would keep customers due to
| support, scaling, monitoring, ci/cd and maintenance. Cheap
| startups could use it as a one-time tool, but I think a lot
| would see the added value they bring.
| flybayer wrote:
| Stay tuned, we're working on the next version of
| Flightcontrol which is in this direction.
| bionsystem wrote:
| Non-ops teams in big corp / public services are often fed up by
| their own IT (slowness, incompetence) and want to deploy,
| budget lines for recruiting devops/sysops is sometimes
| different than software/platform licenses, even if the solution
| is sub-optimal.
|
| Disclaimer I'm an SRE/sysops and went through a bunch of those
| projects where sometimes entire department see (often shadow)
| IT from contractors as the only solution moving forward.
| master_crab wrote:
| Terraform _used_ to solve the AWS infrastructure problem. But
| at a certain scale it becomes the problem.
| balls187 wrote:
| Is this an issue with Terraform, or "infrastructure-as-code"
| in general?
| master_crab wrote:
| Very much an IaC trait.
| hanikesn wrote:
| >Terraform is there specifically to solve the Aws
| infrastructure complexity
|
| No, terraform passes AWS complexity 1:! onto you, it just
| allows you to tackle it in an ordered fashion.
| mannyv wrote:
| Terraform isn't there to resolve the complexity of aws, it's
| there so you can manage tour aws deploy more easily.
|
| In fact, terraform exposes the complexity of AWS, since with
| terraform you need to hook everything up manually.
|
| And avoiding vendor lock in is an illusion. Everyone is locked
| in to some extent. Just design things so you can move providers
| by understanding your system and architecting it correctly.
|
| Not taking advantage of extra capabilities vendors provide you
| is just stupid. SQS/lambda is great. Why avoid it, because one
| day in the far future you might move to GCP? Protip: if you
| move to GCP (or Oracle cloud, or IBM cloud, or CloudFlare, etc)
| you're going to rebuild everything anyway.
|
| For larger companies this will get shut down, because the idea
| of some random team deploying to the cloud by themselves is a
| security breach that hasn't been reported yet.
| BoorishBears wrote:
| I liked Flightcontrol, found it more reliable and less finicky
| than Cloud Build + Cloud Run, but it was too expensive for me.
|
| They introduced a cheaper plan since I tried it, but it's missing
| the main feature that I actually think makes FC worth it (preview
| environments)
|
| I know not everyone wants to get in on the Vercel Cartel model of
| excessive free-tier generosity made up for by 1000% markups at
| scale... but $400/month is tough to swallow when you barely need
| $50/month of compute to handle your production workload.
| gervwyk wrote:
| Same problem, used them for about a year. Nice experience but
| too pricey. also escalated our aws fees, perhapsa good idea,
| but too pricey for what we need.
| hshdhdhehd wrote:
| Nice idea. I work at SP500 corp and we have platform teams
| provide this. I always wondered if it could be a startup. My
| reservation with tbis is tbe classic one: not open source. But I
| totally get why it isn't. Although FOSS might work as the value
| (at work and here too) is in having someone in a Slack channel
| that can help if a deploy gets stuck. The code is kind of a
| terraform-esque of sorts.
| eclark wrote:
| I think 'Batteries Included' would interest you, then. Like
| this, it's installable on AWS. It's a whole platform PaaS + AI
| + more built on open source. So Kubernetes is at the core, but
| with tons of automation and UI. Dev environments are Kubernetes
| in Docker (Kind-based).
|
| - https://github.com/batteries-included/batteries-included/ -
| https://www.batteriesincl.com/
| thevivekshukla wrote:
| In general I love the PaaS experience and I can see the value
| Flightcontrol can potentially provide to the companies that work
| mostly with AWS. The free starter plan for individual is tempting
| to try out Flightcontrol, BTW what is the service limit for free
| plan? I could not find it.
|
| I am also working on similar tool[1] but it's bit more niche to
| batch jobs type functionality but not just limited to AWS rather
| it's cloud agnostic.
|
| [1]: Daestro - https://daestro.com
| flybayer wrote:
| There is no service limit on the free plan. It's limited to a
| single user instead.
| slig wrote:
| It's a shame that "Preview environments" are only available on
| the business plan @ $397/m. I guess that it makes sense if you're
| expending $4k+/m on AWS.
| pelagicdev wrote:
| Coolify is your best option here. It has preview environments
| and lots of other built-in features - just the cost of your
| server if you're savvy enough to get things setup yourself.
| https://coolify.io/
| slig wrote:
| Thanks, I was watching a video about Coolify vs Dokploy from
| "Dreams of Code", and I think I'm going to try Dokploy first.
| the_real_cher wrote:
| Seems like AWS should offer something like this.
| evantbyrne wrote:
| They do with app runner, but last I checked, for some reason
| services were capped at low CPU/Memory and didn't allow basic
| ECS features like attached storage. I think they also had
| another one... AWS is very fragmented and strange.
| coredog64 wrote:
| Dollar dollar bills y'all: https://aws.amazon.com/managed-
| services/
|
| They offer two discrete services. One is a simplified AWS where
| the interface is something like Service Now and you don't have
| access to the environment to make control plane changes. The
| second (and newer) offering is that they will onboard to your
| existing AWS operating environment and assist with running your
| applications.
| the_real_cher wrote:
| I worked on one of the first aws managed services that
| integrated directly with service now back in the early 2010's
| at G.E.
|
| They laid off my whole team because AWS started doing our job
| and better, LOL.
|
| So I see OPs post and it brings back memories.
| ramses0 wrote:
| Pour one out for Flight Control, the $0.99 phenom of an app back
| in the early iOS days.
|
| It came to mind due to the iOS 26 "Games" app reminding me of
| 12-y/o "Achievements" that now only exist as flags in a database.
| atonse wrote:
| That was such an amazingly simple, well executed, and fun game.
|
| Thanks for the reminder.
| languagehacker wrote:
| There's definitely a market for something like this, because most
| software companies at a certain size end up needing to build
| something like this. The real question is, how much work will you
| need to do to fit your current software to their paradigm in
| order to get the benefit? For a newer project, there's likely
| little sunk cost, but for anything that's already
| productionalized, I don't doubt that the rework -- particularly
| around all the devops bits and pieces -- will likely be
| significant. And then of course, from a strategic standpoint, you
| need to balance the risks vs. rewards of hitching your wagon to
| Flightcontrol's set of conventions.
|
| There will be a really solid chunk of projects that find good
| cost savings using this platform -- especially teams that are
| resource-constrained on devops and don't consider it their core
| competency.
| CuriouslyC wrote:
| Data point: I wouldn't use a service for this, but I can see that
| there are plenty who will. The defensible moat is pager duty as a
| service, every engineering org on the planet will push management
| for that.
| infecto wrote:
| Can we fix the title? It's not AWS PaaS but a PaaS built on top
| of AWS. I thought it was a new service being launched by AWS.
| ChicagoBoy11 wrote:
| I had the exact same reaction, and then when reading some of
| the copy thought to myself: "omg, can't believe they are being
| so degrading to how clunky their own dashboards and things
| are!" And then it hit me...
| rco8786 wrote:
| Ditto
| dang wrote:
| We've changed the title now to what the page says. (Submitted
| title was "Flightcontrol: AWS PaaS")
|
| Submitters: " _Please submit the original source. If a post
| reports on something found on another site, submit the latter._
| " - https://news.ycombinator.com/newsguidelines.html
| jakespracher wrote:
| Use it and like it. If using aws is a requirement but you don't
| want to get bogged down with their user experience it's worth it
| IMO.
|
| Have run into some aws quirks leaking out of their abstraction.
| But personally that has only made me say "man if they couldn't
| figure out how to make this clean, I would have been toast
| dealing with it on my own"
| dewey wrote:
| Similar and not tied to a cloud provider: https://dokku.com
| bpicolo wrote:
| Not similar - dokku doesn't support distributed compute. It's a
| platform intended for use on a single server.
| josegonzalez wrote:
| Dokku maintainer here.
|
| Dokku supports distributed compute via our k3s scheduler
| plugin. This can setup its own k3s cluster or connect to an
| existing Kubernetes cluster and deploys helm charts on this
| clusters for your app.
| kolanos wrote:
| Please provide links for the docs to this, as this was a
| misconception I had about Dooku as well.
| evantbyrne wrote:
| I built something very similar to this a few years ago, sold it
| for way less ($3/service), and ultimately decided not to spend
| money marketing it. Building the product made it super clear that
| AWS costs were grossly inflated, which they hid with dark UX, and
| I wanted to help small teams and hobbyists. Today, if you are a
| small team that doesn't really need more than one large VPS, you
| should seriously consider Docker Swarm. Not to say that
| Flightcontrol looks bad. In fact, it looks quite nice. Something
| like this could save you a lot of money if you would otherwise
| need full-time devops.
| achandlerwhite wrote:
| Can you elaborate on Docker Swarm? I thought it lost out to
| Kubernetes and was effectively dead.
| evantbyrne wrote:
| Swarm never died. Kubernetes was designed for an entirely
| different level of scale and there is inherent complexity in
| that. Whereas starting a production-ready container service
| with Swarm only takes a few commands on a fresh Docker
| installation.
| lightningspirit wrote:
| I've been using Docker Swarm for almost 6 years now deploying
| entire stacks for customers on top of it -- it's stable and
| incredibly cheap to maintain.
| gregorvand wrote:
| Trust suggestion: make it easier to find photos of the founders,
| than the investors.
| esafak wrote:
| Wait ... where _are_ the founders?
| burkaman wrote:
| Here, I guess:
| https://www.ycombinator.com/companies/flightcontrol
|
| It is very strange to have headshots of individual investors
| on the page that would normally have pictures of your team.
| flybayer wrote:
| Good suggestion, our company page is updated to include the
| founders
| coolgoose wrote:
| I am still happy with northflank. A bit more infra provider
| independence is nice to have. (we are actually moving from gcp to
| aws )
| 8cvor6j844qw_d6 wrote:
| Skimmed the docs but does Flightcontrol allows a cost cutoff?
|
| I wanted to go with AWS but ended up with Digital Ocean / Vercel
| for personal stuffs due to concerns on AWS horror bills.
| flybayer wrote:
| No, but we support cost budget alerts.
| endriju wrote:
| I think the problem with these general-purpose PaaS on top of
| Cloud is exactly that they're general-purpose. You will run into
| limitations and issues as soon as you start doing things only
| 5-10% of their customers need, like for example running
| privileged docker containers in kubernetes or wanting to manage
| parts of your infra with terraform. I'd much rather see tools
| helping me deploy one particular niche use case in Cloud really
| well. BTW I'm trying to follow this mantra while building
| https://staticbot.dev
| roncesvalles wrote:
| And their value prop that you need expensive hard-to-find AWS
| DevOps Engineer _s_ to run your AWS infra is just fear-
| mongering.
|
| I think people vastly overestimate how hard it is to learn AWS.
| It may seem daunting at first but it only takes like a week --
| one good YouTube series to cover the basics like IAM, and a lot
| of playing around with the GUI console, CloudFormation, and
| pestering support till it all clicks. Multiple backend devs in
| your team should be able to own your CloudFormation/Terraform
| scripts and your cloud infra. I basically did exactly this in
| my new grad SWE job.
|
| Just fucking learn it. You don't need to hire someone for every
| little thing. Don't treat AWS like some complex arcane machine
| that only a 3x AWS-certified "Cloud DevOps Engineer" with 10
| years of experience should touch. And for the love of God don't
| add more 3rd party layers like TFA. Most of the world is raw-
| dogging AWS, why is your company an exception?
| johnthuss wrote:
| Amazon has their own PaaS offering called Elastic Beanstalk, with
| support for running docker containers and other popular
| platforms. It's not complicated to set up and is customizable if
| you need to tweak things. Any idea how Flightcontrol compares to
| this?
| whs wrote:
| We acquired a company that use EB and they have no dedicated
| DevOps engineer. It was bad because every deploy is a full VM
| boot which takes a long time and you can't do things you can do
| with Argo Rollouts. We migrated them to EKS.
|
| I casually asked our account manager "Do you know any local
| customer with EB success story?" Their answer was "Do you want
| to be one?"
| smt88 wrote:
| EB is buggy garbage. We switched to FlightControl to get a
| similar experience without the bugs and headache.
| jimt1234 wrote:
| > Flightcontrol gives our team the power to manage bare metal AWS
| ...
|
| "bare metal"? Hmmm. I think we have different definitions of that
| phrase.
| this_user wrote:
| All we need need now is "PaaS as Code" (PaC) services as the next
| iteration of DevOps stacks that increasingly border parody.
| birdalbrocum wrote:
| Why web developer culture is so annoying when it comes to naming
| things? Serverless? It is actually a server. Flight control?
| Nothing to do with airports or flights or whatsoever.
| dewey wrote:
| "Deploying" a new feature into "staging" also doesn't have to
| do anything with a battle. Naming is hard and most project
| names just pick a fun name.
|
| Your point about "serverless" I can understand, but "Flight
| control" seems like a great name for a product like that.
| kube-system wrote:
| Creating new words from existing words or concepts is how
| language works. In fact, "airport" is an example of this...
| ports were originally for boats.
|
| New terminology may sound strange to people who are not
| familiar with it, but if people start to adopt it, it becomes a
| normal and accepted word. Basically every word has gone though
| this process at some point.
|
| And brand names are often witty puns or irrelevant words,
| intentionally. Using descriptive words for a brand is legally a
| bad idea, because this can disqualify you for trademarks. The
| point of trade marks is to uniquely identify the offering -- if
| you named it descriptively you risk losing this. Apple
| computers are not fruit, and Windows computers are not
| transparent glass. If you named your computer "computer" you
| wouldn't have a brand, and nobody would be able to know what to
| refer to _your_ computer.
| nemothekid wrote:
| I wonder how many of these exist at every company. At $dayjob we
| have built something similar over the years. We have a custom
| load balancer that will query ECS, provision certificates with
| lets encrypt and even provision domains inside Cloudflare. We
| also have deploy previews, and various services on lambda
| function urls. We used to use mesos but transitioned to ecs, so
| we even have a homegrown "chronos" for running scheduled jobs on
| ecs.
| SOLAR_FIELDS wrote:
| This is the end result of the "but kubernetes is too
| complicated" argument. You end up hand rolling all of the
| things it gives you out of the box. I'm sure you have your
| reasons for not using kube, but every one of those things you
| mentioned you get in a standardized way with kube
| nemothekid wrote:
| We were on Mesos before so k8s complexity wasn't the deciding
| factor. If I cared about being could-agnostic, I would have
| gone the kubernetes route. The main factor was we decided to
| move as much as possible to aws managed services so that we
| wouldn't be responsible for their operation. Once we have
| made this decision, then paying the premium for EKS over ECS
| Fargate didn't make much sense.
|
| From there a lot of our custom software is just adapting the
| AWS platform for our taste. For example, we define a lot of
| our routing configuration using docker labels (similar to
| Traefik), so we needed a reverse proxy that could handle
| that.
| coredog64 wrote:
| > so we even have a homegrown "chronos" for running scheduled
| jobs on ecs
|
| EventBridge scheduler is finally available in GovCloud
| tracker1 wrote:
| Wow, they are definitely targeting Heroku with this...
| specifically calling them out towards the end of the page.
|
| That said, I'm surprised that Azure and GCP don't already have
| similar service offerings... I'm not sure about nixpacks over
| direct Dockerfile usage though. Would also be nice to see a
| WebASM package system as well for single ip/socket services and
| web-service request handlers. Simplify the application layer as
| much as possible and make logging via line-separated json on
| stdout the norm... add layers to relay logging and handle TLS
| termination. IT just makes sense... it also makes sense to bundle
| services onto fewer servers based on actual ram/cpu usage. Maybe
| an easy button for redundancy, and that's it.
|
| There's a lot of appeal in what fly, deno, cloudflare and others
| are offering but to a broader range of options than just JS focus
| with WebASM as a minor afterthought with weird limitations in
| practice.
| arccy wrote:
| at least for GCP, isn't that cloud run?
| kolanos wrote:
| Just reading over the docs, you'll need a lot more GCP
| services than Cloud Run to encompass what Flightcontrol is
| managing for you. The Cloud Run analog is Fargate. Which is
| only the container orchestration piece.
| kolanos wrote:
| Looks like you can use your own Dockerfile or a container
| registry. Suspect nixpacks are just a recommended starting
| point for people looking to get up and running quickly.
| MrDarcy wrote:
| Is the paas built on Kubernetes?
| kolanos wrote:
| Looks like it is ECS with either Fargate or EC2. If you don't
| need more control over your containers, Fargate is a good
| default.
| freshnode wrote:
| Using it. Moving off it.
|
| RDS public by default (!), and the private config just removes
| the public IP address rather than puts in private subnet. Causes
| it to fail CIS benchmark which is requirement for FTR.
|
| When I raised it I was told I was wrong.
|
| I think there is a good future for the product but one size fits
| all config comes with downsides. IMO Would be better if it was
| IaC but with pre built "blocks" app, cache, etc, which you could
| easily customize. I also think the pricing is too steep for your
| average scaling bootstrapper which is where Heroku et al shined.
| flybayer wrote:
| RDS has been default private for probably 6 months or longer.
|
| > Would be better if it was IaC but with pre built "blocks"
| app, cache, etc, which you could easily customize
|
| We are working on a major new product version that does exactly
| this ;)
| bdcravens wrote:
| While I'm sure the implementation isn't the same, Cloud66 has
| been doing this for a long time.
___________________________________________________________________
(page generated 2025-10-06 23:01 UTC)