This page says bundle size is 14MB: https://blackboard.sh/electrobun/docs/
HN user
perpil
Founder of Speedrun https://speedrun.cc Speedrun is markdown to build tools. It's an extension to GitHub markdown to prompt for inputs, get temporary AWS credentials, run Javascript and reference configuration so your READMEs, runbooks and documentation can do what they describe with a click.
Consider removing this from the landing page if you want to be taken seriously: "we are in the pursuit of greatness. fueled by caffeine, nicotine, and pure chaos"
Agreed, maybe a forest fire or lightning strike might have made it more obvious that charring preserved. Charcoal in a campfire could have easily disappeared in the next fire.
They do give Leonardo a lot of credit for a single sentence, but it may be the first documented instance of this charring technique.
This is very thorough, but I have a few things to add if you are using Node 22. I benchmarked Node 22 earlier this year using something similar to the light benchmark. https://speedrun.nobackspacecrew.com/blog/2025/07/21/the-fas...
I found that Node 22 had ~50ms slower coldstarts than Node 20. This is because the AWS Javascript V3 SDK loads the http request library which became much heavier in Node 22. This happens on the newly released Node 24 as well.
I recommend that if you are trying to benchmark coldstarts on Lambda, you measure latency from a client as well. The Init Duration in the logs doesn't include things like decrypting environment variables which adds ~20ms and other overhead like pulling the function code from S3. The impact of this manifests when comparing runtimes like llrt to Node, the Init Duration is faster than Node, but the E2E time from the client is actually closer because the llrt bundle size is 4-5MB larger than Node.
Its predecessor (mkdocs material) supported blogs via a plugin and rss feeds via a mkdocs plugin (https://guts.github.io/mkdocs-rss-plugin/). I don't believe it supports blogs yet according to this: https://zensical.org/compatibility/#phased-transition-strate... but will in the next phase when it supports plugins.
It doesn't support loading content from a database that I'm aware of, it uses markdown files on disk as input.
My read of this: https://www.alaskaair.com/content/about-us/customer-commitme... indicates you should be able to get a discount code of $50 if your flight was delayed 3 hours if you ask them.
This is not about the AWS Console. It is talking about the customer's site hosted on CloudFront. It is possible to cross wires with user sessions when using CloudFront if you haven't set caching granular enough to be specific to an end user. This scenario is customer error, not AWS.
Also see https://runme.dev for a similar approach or https://speedrun.cc if you'd like it to work straight from GitHub markdown.
The fact you've copied screen.studio so closely leaves a bad taste in my mouth. On the landing page you apply formatting in Google Sheets, just like screen studio does. It's ok to be inspired by screen studio but remember they are mostly a solo dev too so try and be more original.
Not OP but was there 15 years (left Dec 2021) and surprised I wasn't aware of this. I was only aware of a few tools that acted like chatbots to automatically gather context or take action from chime/tt/alarms.
When I was at AWS, I built something so I could run things straight from the wiki. Think cloudwatch queries, aws cli commands etc with user inputs but without all the setup of securely getting the right credentials and formatting inputs. I've rebuilt to run stuff straight from GitHub. Here's it invoking a lambda function straight from a github wiki with user input in 4 lines of code: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
The video on your landing page is too long for my tastes. A 1-5 minute video quickly showing the features would have more impact than your 20 minute walkthrough attempting to show every detail. The 20 minute video is more suitable for the documentation.
I did something like this but it helps you build exact command lines or interact with AWS straight from your GitHub markdown. As a bonus, it very easily lets you prompt the user for inputs and pivot between different accounts. https://speedrun.cc
Servpro doesn't fix heaters, they mitigate fire damage. They came expecting to fix fire damage, not a heater.
Typo on the menu: Acitvity->Activity
I do something like this with https://speedrun.cc except it runs in the browser on top of your markdown in GitHub. This lets you prompt for inputs and run JavaScript and use a toolbar to context switch. For command lines it copies the command to the clipboard so you can run it.
Neat, you might also look at https://speedrun.cc for ideas. It's a slightly different space, it's markdown to wrap tools with UI's instead of to plot things, but the way I enable you to prompt the user and run little bits of javascript might be of interest to you.
The Mom Test teaches you how to ask the right questions to make sure potential customers actually have a need for and will pay for what you are building vs. lying to be polite. The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you https://a.co/d/8rxZlJ7
Another benefit of BYOK is it simplifies the implementation. You don't need to spend as much time protecting against the attack vector where they rack up a big bill against your key.
DynamoDB also makes for a nice fine grained secrets manager with their new table resource policies: https://speedrun.nobackspacecrew.com/blog/2024/06/27/using-d...
I like the integration with slack and the inline execution of steps. I've been working on a similar product with https://speedrun.cc but it just piggybacks on GitHub markdown and most of the execution is done via a deeplink. Reach out if I can help, I've been messing around in this space for awhile.
A workaround for some of the limits of presigned urls like not being able to specify a max file size is to front your uploads using CloudFront OAC and CloudFront Functions. It costs more (.02/GB) but you can run a little JavaScript code to validate/augment headers between your user and S3 and you don't need to expose your bucket name. https://speedrun.nobackspacecrew.com/blog/2024/05/22/using-c...
Presigned post lets you set content-length-range: https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authen... You can specify content length on presigned PUTs, but it needs to be set as a header and added to the signed headers for SIGv4. It can't be set as a query param.
Can you create a size limit on the pre-signed URL?
Yes, if you use the POST method you can set the content-length-range property in your presigned URL form inputs to limit min and max bytes. https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-authen...
The best part of SPL is you get full digital access to the O'Reilly public library, you don't even need to place holds. Most tech books I've ever needed are a search away. https://www.spl.org/books-and-media/books-and-ebooks/oreilly...
"we cannot confirm that no other such instances occurred". I'd like to understand this more. Do they 1. not have a fingerprint of what the exploit looked like because it was indistinguishable from customer behavior? 2. Not have logging necessary to audit this? Regardless, with the added monitoring to detect suspicious activity, do they also have the logging to see everything a bad actor did if there is a new exploit?
Markdown lacks prompting for inputs and running javascript but is easier to write and offers a quicker update, preview, deploy cycle. Preview and deploy is often a simple save vs. a build and deploy process. By extending markdown to support prompting for inputs and running javascript, you close some of the gaps and get the best of both worlds.
For a wilder idea of what you can do with GitHub and wikis see https://speedrun.cc No AI, so the wikis need to be hand created, but being able to build tools and UIs right into your GitHub documentation is a powerful concept.
"Privacy & settings – where it lives now – is a natural home for it, but we think it should appear elsewhere too."
Seems like the next step would be to send an app push notification before the call and to have a banner that's visible as soon as you log in to the app. Some sort of visual indicator that appears everywhere in the app that you should not be on a call may also reduce an attackers chance of succeeding.
I got the same good chill running down my spine watching this as when I watched Second Reality 30 years ago. I think how they mirrored the music so well caused my brain to just fill in the pieces of the graphics. I was especially impressed at the attention to detail down to the font in the end credits. Hats off, this made my day.