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
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.
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.
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.
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.
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 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.