2
8 Comments

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

on August 5, 2026
  1. 1

    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.

  2. 1

    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?

    1. 1

      Thanks for your comment @yhay81.
      Actually there is laranja plan command which will show you what exactly is going to be deployed before deploying :)

  3. 1

    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?

    1. 1

      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.

      1. 1

        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?

        1. 1

          Thanks you. You can reach me at feras[at]laranja[dot]io

          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

Trending on Indie Hackers
I built a startup-idea scanner. It just told me none of my 3,400 ideas are easy wins. User Avatar 77 comments “I’ll just post on Upwork” is not a client strategy. Here’s what I built instead. User Avatar 60 comments Building a Shopify bundles app for stores with real fulfillment: here's the wedge User Avatar 42 comments I recorded myself using 200+ indie SaaS products cold. Here are the 7 conversion killers that keep showing up. User Avatar 36 comments The Capture Trap User Avatar 33 comments I Just Discovered My Analytics Numbers Are Mostly Fake. Here Is Why. User Avatar 30 comments