Zhengqikk 3732 Update — NoPager’s incident authority UX is now live I’ve just shipped a major OSS UI update based on early security feedback. The incident flow now makes the execution boundary explicit before anything happens: Trigger → Evidence → AI assessment → Policy → Exact action → Exact target → Attempt budget → Approval → Verification → Outcome The worker still has no Docker socket, Docker group, Docker CLI, or arbitrary shell access. Safe Mode remains the default. The first real operations path is intentionally narrow: 3 failed HTTPS checks → incident → AI triage → one bounded restart_container proposal → human approval → restart exactly one enrolled container → external HTTPS + container-state verification I’m now specifically looking for people willing to actually run it on a disposable/non-critical Linux Docker service. I’m much more interested in: “setup failed here” “I don’t trust this permission” “the incident didn’t recover” “this approval UI is missing something” than general product opinions. OSS: https://github.com/nopager/nopager If you’re willing to test the full loop, I’m happy to help personally with setup.

Jacob Paris We are opening the open source program for submissions again very soon!

NEVARLeVrai @jacobparis yes but is my project compatible ?

Chintan @nevarlevrai - you can track here - https://vercel.com/open-source-program

Jacob Paris Your headers are being added twice. When this happens they get merged together and that's probably creating an invalid final value. I'm guessing you've tried to configure the same CORS setup in both Laravel and in Nginx/OpenResty. Removing one of these should fix it When you check your request in the network tab of your browser, you want to see these headers and no duplicates ``` Access-Control-Allow-Origin: https://elkj-pos.vercel.app Access-Control-Allow-Credentials: true ``` Alternatively: the easiest way to get around CORS is to not make any cross-origin requests in the first place. - If you're using a full stack framework like Next.js, you can route your requests through the same-origin Next.js backend toward your API. This might feel like an extra step, but server -> server requests are much faster than client -> server as they're between (or within) datacenters. - You could also use proxy rewrites to route traffic from your app domain to your Laravel Server. We use this to mix Next.js pages into the Discourse platform on this website. https://vercel.com/blog/how-we-run-vercels-cdn-in-front-of-discourse#vercel-as-a-cdn Both of those solutions mean your website is only ever sending requests to its own domain, which eliminates CORS and allows you to use more secure authentication methods like HttpOnly SameSite cookies.

NextBlock™ CMS Thanks for checking this out, @amyegan! What is the current criteria or best path for community open-source starters like NextBlock to be considered for the official Vercel Templates gallery?

Amy Egan I love seeing so many awesome things people have build with shadcn/ui! Thanks for sharing this dashboard toolkit

Vaibhav Gupta Glad to see you liked it!!

Ryu Hi Rodrigo, This is a strong repro. Since the `.65` hosts in the same ranges work, the legacy IPs work, but the `.1` hosts fail for both ICMP and TCP/443 from AS28668, I would not treat this as an app/build issue or normal DNS propagation. It looks more like a route/filtering problem for those specific Vercel anycast endpoints from that ISP path. If you can, I’d add TCP-based traces too, since ICMP can be filtered differently from HTTPS traffic: ``` mtr -T -P 443 -rwzc 100 216.198.79.1 mtr -T -P 443 -rwzc 100 64.29.17.1 mtr -T -P 443 -rwzc 100 216.198.79.65 mtr -T -P 443 -rwzc 100 64.29.17.65 ``` And a direct HTTPS comparison: ``` curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.1 https://aglenos.com/ curl -Iv --connect-timeout 10 --resolve aglenos.com:443:216.198.79.65 https://aglenos.com/ ``` The useful summary is: ``` Affected ISP/ASN: AS28668 Region: Jaú/SP, Brazil Fails: 216.198.79.1 and 64.29.17.1 Works: 216.198.79.65, 64.29.17.65, and legacy endpoints Failure type: TCP/443 timeout, not app 4xx/5xx Temporary workaround: legacy CNAME restored service ``` I’d also send the same evidence to the ISP if possible. From the community side, this is probably enough to show the domain config itself is not the main problem.

Badreladraoui1 *Same issue from Morocco (AS36925 Meditel), full details here:* https://community.vercel.com/t/new-edge-ranges-216-198-79-0-24-64-29-17-0-24-unreachable-from-morocco-as36925-legacy-works/46736

Amy Egan Awesome project!

Amy Egan Love this!

Jose Ramon Wow, I wish I'd seen this when I updated my landing page, but I think I might consider using it for a project I have for a hackathon (H0 v0 + AWS). This is awesome, man!!

Amirreza225 Same problem here!

Ably DevRel Also seeing this problem, is there a change to the process?

Ably DevRel I got a reply on my post about this, apparently templates are not being accepted https://community.vercel.com/t/hitting-404-on-template-submission-form/43614

Pauline P. Narvas We don’t have one in our templates just yet, but why not create your own and share it here?

Kostra Great question! For a community-focused website, I've been using Kostra --- it's a Next.js SaaS boilerplate that comes with auth, user management, and a solid foundation you can customize for community platforms. It handles a lot of the boring setup so you can focus on the community features. Worth checking out if you want a head start!