7 weeks solo: a CLI that deploys your Express/NestJS app to your own AWS or Azure — no IaC
I've been shipping Node backends for years and the deploy step never got better. Either I write infra config that duplicates what's already in my app, or I hand a platform standing keys to my AWS account.
So I built laranja (laranja.io) a CLI that reads your code and deploys it. No YAML, no CDK, no Terraform, no console clicking.
You mark what you already have:
export default http(app); // your Express or NestJS app
export async refreshCache() { … }
export async sendEmails(job: EmailJob) { … }
cron(rate(1, 'hours'), refreshCache)
cron(rate(5, 'hours'), sendEmails)
Then laranja deploy. On AWS that's a Lambda behind a Function URL, EventBridge rules, SQS queues with DLQs. On Azure it's Function Apps and Storage Queues, same app code, one provider field.
Three things I decided early and haven't regretted:
It deploys into your account, from your machine. Your local AWS/Azure credentials, same as running the CLI yourself. My server never receives a key. It only ever sees a JSON description of your infra: 4 routes, 2 crons, 1 queue, never your source. The comparison that pushed me here: the official NestJS platform asks you to create a long-lived IAM user with ec2:*, rds:*, iam:CreateRole and secretsmanager:GetSecretValue, and paste those keys into their dashboard. That policy can read your secrets, forever.
Your code is the only spec. Nothing to keep in sync, so nothing to drift.
There's a way out. laranja eject writes you a real, editable CDK project you own outright. If the magic stops fitting, take the infrastructure and go.
Status: early, but real. Express and NestJS on AWS and Azure are live and deployed daily by me. Free tier is 1 project / 3 deploys a day.
What I'd genuinely like feedback on: is "deploy to your own account" a real selling point, or do most people just want someone else to hold the keys? I've been building on the assumption that the ownership matters. Tell me if I'm wrong before I build another month on it.
Docs: laranja.io/docs
You asked whether ownership deserves another month. I'd say ownership isn't the claim to test. The eject path is, and the test that matters isn't "does the generated CDK deploy", it's "does it deploy onto a stack that's already serving traffic".
Eject plus a manual deploy from clean is the right start, but the case a buyer actually worries about is month eight: real traffic, a queue with messages in it, a database somebody depends on. If eject at that point produces a project that wants to create resources that already exist, then the honest version of "take the infrastructure and go" is a migration with a downtime window, not a handoff. That's the difference between an escape hatch and a promise.
The generic version of this bites well outside AWS. Every tool I've used that owns state has a re-run that quietly stomps something a human added by hand, and you find out during the incident you were using the tool to avoid. If you can demo eject against a live deployment and show it adopting rather than recreating, that's a far stronger answer to your own question than any positioning argument about who holds the keys.
And btw congrats, great idea!
Thanks @to21as. When ejecting the stack name is exactly same as the one you deployed, so AWS/Azure will deploy any changes you add to them manually without any issues. I even tested deploying using laranja and then manually destroying using the CDK and it worked fine. The good part of CDK/Bicep is that diffing happens against the cloud provider, and that's why I hit the breaks when I was thinking about using Terraform as another way to eject, since state syncing is something really needs to be thought of deeply
I believe ownership is important, though possibly even more so after you lose something.
Usually at first, convenience wins. Your only desire is to ship. As costs grow or needs change, being able to bring your infrastructure along feels priceless. Plus, you can still take it with you when you move.
The “way out” part may be just as important as deploying into your own account.
Ownership is a real selling point for a smaller set of buyers, and a weak one for everyone else. Most people still fighting deploys want the pain gone more than they want the keys in their account. The people who care about own account deploys usually already pay AWS or Azure and care about compliance, cost control, or not handing a platform standing credentials. If that is your wedge, make the first successful deploy feel boring: one command, a clear plan of what will be created, and no IAM homework. The free tier can teach the model. Paid conversion will come from the person who already has a cloud bill and hates rewriting the same queue and cron config.
The "no IaC" part is what got me — I've wasted so many weekends wrestling with Terraform configs when I just wanted to ship. Sounds like you're solving the right problem.
The part that stands out is that your server never sees source, only a JSON description of routes, crons, and queues. That is a smaller trust surface than a long lived IAM user, and it is also a claim that could be independently verified by watching network traffic during a real deploy, which would carry more weight than the docs saying so once someone outside the project confirms it directly. On the eject path, has anyone actually run eject on a production app and lived with the resulting CDK for a while, or is that still mostly theoretical at this stage.
Actually I've used laranja to deploy laranja :), with/without ejecting. I made sure to eject and deploy the resulted CDK/Bicep manually to make sure it covers all the resources, and that was a crucial decision for me while building it. Of course the more users start using it, the more cases it will uncover. But for sure I'm committed to this claim
That is a strong signal, dogfooding the eject path on your own production infrastructure rather than only on a demo repo. It also means the messiest edge cases will surface for you first, before a customer hits them, which is a much better place for that pain to live.
Code-derived infrastructure is appealing, but the application source cannot express every non-functional constraint. Concurrency caps, VPC placement, KMS keys, data residency, retry policy, and queue visibility timeouts still need an explicit contract. I would keep those in a small provider-neutral policy layer and show every default in laranja plan, otherwise the “no IaC” abstraction can become hidden IaC. A useful invariant would be deploy, eject, then CDK diff with no resource changes.
There is laranja.config.ts file that will be created after init. From there, you can specify Concurrency, queue visibility time & retry policies. As I will be supporting more resources, I will make sure that these practical cases are covered in the configs
Good foundation. As you add resources, I’d model those as per-resource operational contracts rather than one shared default: concurrency, timeout, visibility, retry/backoff, DLQ, and idempotency. A plan diff that validates those settings against each provider’s constraints would catch many expensive mistakes before deployment.
Thanks @ahmet_ozel, that's what the config file does actually :) you can specify per re-source, or you can simply specify a general config. All explained here in the docs https://laranja.io/docs/reference/config-file
I think “deploy to your own account” is a real selling point, but mainly for teams that have already felt the cost of platform lock-in, security review, or unclear infrastructure ownership. Very early-stage founders may still prefer fully managed hosting, so I’d position this less as “you keep the keys” and more as a clean migration path: start with one command, retain ownership, and eject to maintainable CDK when the abstraction no longer fits.
The trust story would be even stronger if the CLI can show the exact IAM permissions and planned resource changes before deployment. Do you already have, or plan to add, a dry-run/permission manifest?
Thanks — that’s exactly the kind of preflight I had in mind. One addition I’d find valuable is having
laranja planshow the required IAM actions and flag wildcard permissions separately from resource changes. That would let security-conscious teams review both infrastructure changes and privilege expansion before deployment. If it already does this, a sample plan in the docs would make the trust model much more tangible.Thanks for your comment @yhay81.
Actually there is
laranja plancommand which will show you what exactly is going to be deployed before deploying :)The interesting part here is that you’ve made “deploy into your own account” a product assumption, not just an implementation detail.
Since you’re explicitly deciding whether that assumption deserves another month of investment, what evidence would make you confident it’s actually something users choose Laranja for?
Actually, in the product map I will add the option to deploy to laranja's cloud. From my personal experience, when it was time to pick a tool, a lot of companies were hesitant to use Vercel for example or other options just because you have no control over the cloud, so ejecting was not an option. Also, in case of Europe, GDPR was always the first thing we get from legal department when we decided to use a new tool. So I felt like giving full control to the users makes more sense at the launching stage, but my next item on the list is hosting on laranja as well to see the adoption.
That’s helpful context. I appreciate you explaining where that product assumption came from and how you’re thinking about validating it.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Thanks you. You can reach me at feras[at]laranja[dot]io
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.