7 weeks solo: a CLI that deploys your Express/NestJS app to your own AWS or Azure — no IaC - Indie Hackers

Join

Likes

Bookmarks

14<br>Comments

Report

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)<br>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

Feras Allaou

on August 5, 2026

Share

Say something nice to FerasAllaou…

Post Comment

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.

eddzsh

10 hours ago

Reply

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.

IndieHacker07333

13 hours ago

Reply

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.

FounderFlow_57

10 hours ago

Reply

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

FerasAllaou

6 hours ago

Reply

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.

ahmet_ozel

12 hours ago

Reply

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

FerasAllaou

6 hours ago

Reply

I think “deploy to your own account” is a real...