Also this, we disable it when building or deploying apps in DollarDeploy

export SEMGREP_SEND_METRICS=off export COLLECT_LEARNINGS_OPT_OUT=true export STORYBOOK_DISABLE_TELEMETRY=1 export NEXT_TELEMETRY_DISABLED=1 export SLS_TELEMETRY_DISABLED=1 export SLS_NOTIFICATIONS_MODE=off export DISABLE_OPENCOLLECTIVE=true export NPM_CONFIG_UPDATE_NOTIFIER=false

Just add this, it works better than Opus 4.7

vim ~/.claude/settings.json

{ "model": "claude-opus-4-6", "fastMode": false, "effortLevel": "high", "alwaysThinkingEnabled": true, "autoCompactWindow": 700000 }

Wouldn't xhigh or max work better

Because of this https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-...

Is it for managing my software deployed in the customer's cloud environment? Would you support simpler deployment targets, like on premises VMs etc?

At DollarDeploy we developing the platform to deploy apps to VMs with managed services provided, kind of like Vercel for your own servers. Would be interesting to try alien for enterprise customers.

> Would you support simpler deployment targets, like on premises VMs etc?

https://github.com/alienplatform/alien/blob/main/crates/alie... :)

Yep, I work for small companies and already have a sync server that wish to manage centrally for more than just updates

> Download this repository as a zip-file from GitFlic

Please don't do that

Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS.

At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.

I build some projects via pm2 deploy directly on a server and its much faster then vercel

Not every project can be compiled on production server since compiling NextJS might take quite a lot of RAM, I would advise against it.

we have 128ram on our production server I think it will be fine ;)

Turbopack, custom runtime infrastructure on top of AWS Lambda.

Turbopack does not work for every app, I think they skip some build steps when building like typescript validation etc and aggressively cache node modules.

> skip some build steps

There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u...

This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.

> typescript validation

There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.

There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.

> aggressively cache node modules

We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation

Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling

There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.

Unfortunately turbopack have some bugs in bundling. Does not work on some of my projects. Can't reproduce outside of whole codebase, so no ticket.

The biggest issue is missing plugins, but they have an extension point to add them.

Naturally they expect them to be written in Rust, which might be an issue for some then again Vite folks are also going into RIR.

I was prototyping with S3 mounted as filesystem for docker volumes and evaluating solutions for that. GeeseFS cli is the fastest one, here I made a script to mount folder with it from S3 compatible storage:

https://gist.github.com/huksley/44341276d7c269f092e10784959e...

You might want to play with memory params for GeeseFS for better results

Anyone tried to use vinext from Cloudflare in production? Might be faster.

But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.

AI chat for DollarDeploy (platform to automate DevOps, kind of like Vercel for your own servers). Adding more tools to deploy your apps and soon sandboxes.

Working on AI chat implementation for DollarDeploy (platform to automate DevOps, kind of like Vercel for your own servers.

Neat thing about AI chat is that you can write in any language and it will automatically translate and use the right tools (create VPS server, build and deploy app).

UV_DISABLE_AGENT=1 UV_DISABLE_AI_HINTS=1 uv add

:D, and i think they would add some optout telemetry flags too to make this even funnier

lol, underrated comment