标签：#p

Working with files in Linux isn't just about creating and editing them. Sometimes you need to: Archive multiple files into one Compress files to save disk space Share files with others Create backups Linux provides several tools for this, each with a different purpose. Let's simplify them. What is File Compression? File compression reduces the size of a file. Benefits: Saves disk space Faster file transfers Easier backups Reduces bandwidth usage Example: A 100 MB log file might become a much smaller compressed file, depending on its contents. Archive vs Compression Many beginners think they're the same. They are not. Archive Combines multiple files into a single file. Example: photos/ docs/ notes.txt ↓ backup.tar Compression Reduces the size of a file. Example: backup.tar ↓ backup.tar.gz 👉 tar archives files. gzip compresses them. 1. Create an Archive with tar tar -cvf backup.tar Documents/ #Create an archive tar -tvf backup.tar #View archive contents tar -xvf backup.tar #Extract an archive Options: c → Create v → Verbose (show progress) f → File name x → Extract Best for: Backups Bundling multiple files Moving folders 2. Compress with gzip Compress a file: gzip file.txt # Creates file.txt.gz # Result file.txt.gz gunzip file.txt.gz # decompress gzip -k file.txt # Keep original file Best for: Log files Large text files Saving disk space 3. Archive and Compress Together Most common command: # Create compressed archive tar -czvf backup.tar.gz Documents/ # Extract tar -xzvf backup.tar.gz Options: z → Use gzip compression 👉 This is one of the most common backup commands in Linux. 4. Working with ZIP Files # Create ZIP zip -r project.zip project/ # Extract unzip project.zip # List contents unzip -l project.zip Best for: Sharing files with Windows users Cross-platform compatibility 5. Compare the Tools Tool Purpose Best For tar Archive files Backups gzip Compress files Saving space tar + gzip Archive and compress Linux backups zip Archive and compress Sharing files across

I think many of us have already noticed that a growing number of open-source projects and libraries are moving towards commercial or dual-licensing models. In the .NET ecosystem, several widely used libraries have taken this path over the past year or so. AutoMapper and MediatR introduced commercial editions under a dual-licensing model, Fluent Assertions began requiring a paid licence for commercial use with version 8, and MassTransit 9 became a commercial product. These libraries were widely used in .NET applications and I mean widely used. Many projects treated them almost as a standard part of the ecosystem. Now, the same change is reaching the frontend world. PrimeTek recently announced that future major versions of PrimeNG, PrimeReact and PrimeVue will no longer be released as open source. All these projects were widely adopted, and many commercial applications depended heavily on them. Their licensing changes were primarily driven by the cost of long-term maintenance, but this raises a broader question: Is AI also changing the world of open source? You have probably already read many articles about code inflation. With AI, we can generate a huge amount of code in a very short time, even if the quality is sometimes questionable. The same thing is happening in open source. Maintainers can now receive more AI-generated issues, pull requests and feature requests than they can realistically review. Producing code has become cheaper, but understanding, testing and maintaining that code still requires significant human effort. Maintainers can become overwhelmed very quickly. AI may also discourage some developers from publishing their work publicly. Even small experiments, educational repositories and proof-of-concept projects can become training material for large language models. Some authors may therefore decide to keep their repositories private because they do not want AI companies learning from their work without permission, attribution or compensation. Licens

It's 3 AM. Your customer can't sleep. They open your SaaS product on their phone to check one number — whether their pipeline is healthy, whether something needs their attention before morning. What they see instead is a wall of 47 widgets, three unlabeled charts, and a date picker buried behind a gear icon. They close the tab. They don't come back. This isn't a hypothetical. In 2024, Userpilot benchmarked 62 B2B SaaS products and found that only 37.5% of new users ever reach activation — the point where they actually experience the value they signed up for ( Userpilot User Activation Benchmark Report, 2024 ). The rest poke around a dashboard, get overwhelmed, and leave. A Nielsen Norman Group study found that decision-makers spend roughly 2.3 seconds scanning a dashboard before deciding to engage or abandon it. Your analytics page is the screen where retention is won or lost. And most SaaS companies are losing. The Four Ways Dashboards Fail 1. The Data Dump The most common failure: treating a dashboard like a warehouse. Every stakeholder gets a tile. Three years in, the dashboard has 34 widgets and nobody can find anything. One UX audit of a banking analytics platform found that 11 of 23 displayed metrics were never clicked — four drove 80% of all sessions. After removing 17 widgets, adoption rose 41% in six weeks ( SaaS Dashboard Design: How to Build Dashboards Users Actually Love ). The team asked, "What data should we show?" The right question is: "What decision does this user need to make in the next 30 seconds?" 2. No Default Narrative A dashboard that shows "$42,000 MRR" with no trend arrow, no comparison, and no time period label forces the user to do mental math. A number without context is a snapshot; a number with a trend is a story. Research consistently suggests that 5–7 primary metrics is the maximum before cognitive load degrades comprehension — and for the headline view, 3–5 is ideal ( SaaS Dashboard Design Guidelines ). When different parts of a das

Picture a moment every person who runs an AI agent knows. A task is halfway done and starting to go wrong. The agent took a weird turn a few steps back and now it is confidently heading somewhere bad. You have to decide fast on this. Do you step in? And if you do a quick "wait, check your work" nudge will that actually fix it? Or do nothing? Or worse knock a run that was about to recover on its own off the rails? That question is the whole project. Here is the honest short version of what I found. Detecting a failure is not fixing it A lot of recent agent research is about failure attribution — figuring out which step in a long run broke everything. Useful but it stops one step short of what you need when you are on call. Knowing where it broke is not the same as knowing what to do about it . So I asked a blunter question: given a failure, which fix actually recovers the run and which ones quietly make it worse? To answer it without fooling myself I rewind each failing run to the exact step where it went wrong, apply one fix, let it play forward and check the real answer against a hard ground truth no LLM grading another LLM. And I always compare against a "do nothing" control, because some runs recover on their own, and I did not want to give my fixes credit for that (or miss a "fix" that's actually worse than leaving the agent alone). What a capable agent actually gets wrong First surprise: a decent agent mostly doesn't fail in the dramatic ways people worry about. It rarely loops, rarely forgets to answer, rarely fumbles a tool that throws an error in its face. It fails in two quieter ways and both are the same underlying mistake: acting on the surface of the situation instead of the real thing underneath. It makes up an answer it could have looked up. The fact it needs is sitting right there behind a tool call it just never makes, so it fills the gap with something plausible. Reads "manager: #202," never looks up who #202 is, asserts a name anyway. It trusts a t

Hey everyone, I'm excited to share my brand-new C# Crash Course for Beginners on YouTube! 🎉 For those of you who are new here, I'm Amir, a software developer who enjoys learning new technologies and creating programming tutorials that are practical, beginner-friendly, and straight to the point. If you've been thinking about learning C#, this course is the perfect place to start. C# is one of the most popular programming languages in the world and is widely used for desktop applications, web development with ASP.NET, cloud services, game development with Unity, and enterprise software. Combined with the power of the .NET ecosystem, it provides an excellent foundation for building modern applications. In this one-hour crash course, we'll start from the very beginning by setting up the .NET development environment and learning the essential command-line tools. From there, we'll gradually build our understanding of the language through practical demonstrations and live coding examples. Throughout the course, you'll learn: How to install and configure the .NET SDK Using the .NET CLI and .NET Script Variables and data types String interpolation Arithmetic, comparison, and logical operators Conditional statements Loops Methods and functions Arrays and collections Lists, Dictionaries, and HashSets LINQ fundamentals Classes, objects, and Object-Oriented Programming (OOP) Records and modern C# features Pattern Matching You'll also get a preview of a real-world application that we'll build together in a future tutorial series, showing how these concepts come together in an actual project. This course focuses on building a strong understanding of C# fundamentals. Topics such as asynchronous programming with async and await are intentionally left for a dedicated tutorial, where we can explore them properly with practical examples. Whether you're completely new to programming or coming from another language like Java, Python, JavaScript, Go, or Rust, I hope this course helps make

Block Kit, signature verification, and the design decisions that stop a button click from becoming an incident. That screenshot is a bot asking permission to delete an EBS volume. Clicking Approve Remediation snapshots the volume, waits for the snapshot to complete, deletes the volume, and edits the message to say what happened. Getting that to work is mostly plumbing. Getting it to work safely , so that a stale click, a replayed request, or a resource someone protected in the meantime cannot cause damage, is the interesting part. This walks through both, using the Slack adapter from FinOps Sentinel . The shape of the problem Slack interactivity is two separate channels that only look like a conversation: Your app ──── incoming webhook ────▶ Slack channel │ user clicks │ Your app ◀─── HTTP POST ──────────────────┘ (a completely new request, from Slack's servers) The click arrives as an unauthenticated POST from the public internet to whatever URL you registered. Nothing about the request proves it came from Slack, or that a human clicked anything. That is the security problem in one sentence, and everything below follows from it. Part 1: Setting up the Slack app Create the app and get a webhook api.slack.com/apps → Create New App → From scratch Name it, pick your workspace Incoming Webhooks → toggle On → Add New Webhook to Workspace Choose a channel, click Allow , copy the URL SLACK_WEBHOOK_URL = https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXX Webhooks post to exactly one channel and cannot read anything. For a notification bot that is the right amount of privilege: no OAuth flow, no bot token, no scopes to review. Enable interactivity Interactivity & Shortcuts → toggle On → set the Request URL: https://your-domain.example/callbacks/slack Locally you need a tunnel: ngrok http 8000 # → https://a1b2c3d4.ngrok.app # Request URL: https://a1b2c3d4.ngrok.app/callbacks/slack The free ngrok URL changes on every restart, and you must update Slack each time. Save your

Full title: [Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Specific Fields or Types, Memory Representation of Complex Types, and Repr Rust 1.14.1. repr(Rust) Remember the example in the previous article? That example used repr(C) , and the limitation of the C representation is that all fields must be placed in the same order as they are defined in the original struct. repr(Rust) is the default representation. It intentionally provides fewer layout guarantees than repr(C) : the compiler may reorder fields, and two types with the same fields in the same order are still not guaranteed to share a layout. Because the compiler may reorder fields (for example, placing larger fields first), padding can often be reduced. In the Foo example from the previous article, one possible optimized layout needs no padding. With fewer guarantees about layout, the compiler has room to rearrange things and produce efficient code. If repr(Rust) is used, then one possible memory layout of the Foo struct from above is: Code Field Type Size Default Representation Padding Final Alignment #[repr(Rust)] struct Foo { long: u64, 8 bytes 8-byte aligned 8 bytes normal: u32, 4 bytes 4-byte aligned short: u16, 2 bytes 2-byte aligned small: u8, 1 byte 1-byte aligned tiny: bool, 1 byte 1-byte aligned } Total 16 bytes The compiler first orders the fields by size, putting the largest first so that it can determine what alignment the struct should use. In this example, u64 is the largest and takes 8 bytes, so the struct is aligned to 8 bytes The compiler then looks at the remaining fields and sees that their total size is exactly 8 bytes, so it can place them together and avoid padding In the end, this struct only needs 16 bytes, which saves half the memory compared with repr(C) This is more efficient, but compilation time may be a little longer 1.14.2. Packed Layouts You can tell the compiler that no padding is needed between fiel

The Interative AI Notepad for Meetings Discussion | Link

submitted by /u/Vivid-Leek753 [link] [留言]

Every bootstrapped SaaS founder hits the same wall. You've built a product. You have organic signups. You're at $3-5K MRR growing 5% per month. At this rate, you'll hit $1M ARR in approximately... never. The conventional wisdom says: hire a salesperson. But you can't afford one. A decent SaaS AE costs $80-120K base plus commission, and the good ones want to sell for funded companies with brand recognition. Here's the good news: you don't need a sales team to reach $1M ARR. You need a system. And you — the founder — are the best salesperson your company will ever have, because you understand the customer's problem better than anyone you could hire. This playbook covers the tools, processes, and scripts to run founder-led sales from zero to a million ARR. Why Founder-Led Sales Wins At $10K MRR, your entire company revenue is $120K per year. Hiring a salesperson at $80-100K base means 70-80% of revenue goes to one person — before ramp time (3-6 months), tools, and leads burned while learning. Meanwhile, you already have the context. You built the product. You can answer any objection without checking with a product team. According to OpenView Partners' SaaS Benchmarks, companies in the $1-5M ARR range with founder-led sales close deals 40% faster than those with early sales hires, primarily because founders can make pricing and scope decisions on the spot. Companies like Bannerbear and many IndieHackers founders built to $1M+ ARR with the founder doing all the selling. It's often optimal. Phase 1: $0 to $10K MRR — Manual Everything Your job is to find the first 10-20 customers who will pay you, use your product, and give you feedback. The Tools ($0-50/month) CRM: A spreadsheet. Notion, Airtable, or Google Sheets. Don't buy a CRM until you have 50+ leads. Email: Your personal email via Google Workspace ($6/month). Meetings: Google Meet (free) or Calendly free tier. Enrichment: Apollo.io free tier or manual LinkedIn research. The Process Step 1: Build a target list of 10

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The Initial Goal: "Upgrade and Secure" Like many developers, I recently fell into the trap of assuming that "smaller is always better, and newer is always safer." I decided to upgrade my terminal-based web UI project, py_terminal , to the bleeding-edge python:3.15-rc-alpine Docker base image. The logic was sound: Alpine Linux has a much smaller footprint, meaning a smaller attack surface. Python 3.15 Release Candidate would give me early access to performance improvements and patches. What followed was a cascading series of build failures that taught me a valuable lesson about container architecture, Python's C-API, and what actually makes a container secure. The Descent into Dependency Hell The moment I pushed the Dockerfile update and ran docker build , the pipeline exploded. 1. The Missing Wheels The first error was abrupt: ERROR: No matching distribution found for litellm==1.93.0 Because I was combining a release candidate of Python (3.15-rc) with Alpine (which uses musl libc instead of the standard glibc ), pre-compiled binaries (wheels) simply didn't exist for several of my packages. pip was forced to download raw source code and build from scratch. 2. The Rust Compiler (Wait, Rust?) One of litellm 's underlying dependencies is fastuuid , which is written in Rust. Because pip was building from source, it attempted to download the Rust toolchain ( cargo ). It immediately failed: Error loading shared library libgcc_s.so.1: No such file or directory Because Alpine is so incredibly stripped down, it didn't even have the basic C runtime library ( libgcc ) required to run the Rust compiler. 3. Fighting the PyO3 API Determined to win, I added the heavy build tools to Alpine ( apk add build-base cargo libffi-dev ). The build got further, but then crashed while compiling tiktoken and pydantic-core . The bridge between Rust and Python is handled by a library called PyO3 . It explicitly re

If you have ever bought a domain on Namecheap to redirect traffic to your main web app, you might have hit a frustrating wall: Namecheap's free "Domain Redirect" feature works fine for plain http:// requests, but it completely falls flat when someone hits https:// . Browsers try to perform an SSL/TLS handshake before following the HTTP redirect header. Because Namecheap does not issue a free SSL certificate for basic domain forwarding, your users end up seeing a scary "Your connection is not private" error. Here is how to set up a full, seamless redirect from an old domain ( snapseek.co ) to a new domain ( snapseek.app ) using Cloudflare's free tier. This approach handles both HTTP and HTTPS, while preserving all incoming URL paths and query parameters. The Big Picture Instead of serving traffic through Namecheap's basic forwarding servers, we hand off DNS management to Cloudflare. Cloudflare acts as a reverse proxy, provides a free universal SSL/TLS certificate, and handles the redirection right at the edge using its modern Single Redirect Rules engine. Step 1: Add Your Domain to Cloudflare Log into your free Cloudflare account (or sign up if you do not have one). On your dashboard under the Home tab, click Add a domain . Type in your source domain (e.g., snapseek.co ) and choose Quick scan for DNS records . When prompted to select a plan, scroll down to the bottom and pick the Free plan. Cloudflare will scan your existing DNS setup. Scroll down and click Continue to activation . Cloudflare will display a pair of custom nameservers (for example: ada.ns.cloudflare.com and sam.ns.cloudflare.com ). Copy these down. Step 2: Update Nameservers in Namecheap Log into your Namecheap account and go to your Domain List . Click Manage next to your domain ( snapseek.co ). Find the Nameservers dropdown section. Switch it from Namecheap BasicDNS to Custom DNS . Paste the two Cloudflare nameservers into the fields and click the green checkmark to save. Note: DNS propagation usual

Innovation is often described as the creation of something entirely new. In reality, many breakthrough ideas are simply successful mechanisms transferred from one domain into another. Nature inspired aerospace engineering. Video game matchmaking algorithms influenced logistics. Immune systems inspired cybersecurity. Financial risk models are now being applied to supply chain resilience. The challenge isn't a lack of ideas. The challenge is discovering where those ideas already exist. The Innovation Gap Organizations spend billions of dollars every year on research and development while unknowingly solving problems that have already been solved somewhere else. Traditional consulting typically searches inside the client's industry. Traditional search engines retrieve documents. Traditional LLMs generate text. None of these systems are explicitly designed to answer a much more valuable question: Which proven mechanism from an entirely different industry can solve my problem? This question became the foundation of what I call the Innovation Wormhole . From Knowledge Retrieval to Mechanism Transfer Instead of retrieving documents, the system retrieves mechanisms . Instead of matching keywords, it matches problem structures . Instead of generating ideas from scratch, it transfers validated solutions between industries. Imagine a manufacturing company struggling with predictive maintenance. Rather than searching only industrial papers, the platform might discover that astronomical signal processing uses nearly identical anomaly detection techniques. The recommendation isn't merely: "Read this paper." It becomes: Why the solution works Which assumptions remain valid Required modifications Technical risks Expected ROI Evidence supporting the transfer This is knowledge transfer rather than information retrieval. The Core Architecture The platform is organized as a pipeline of specialized reasoning modules. 1. Problem Decomposition The customer's problem is transformed into a

Handoffs are useful when a specialist agent needs to take over a task. They also make cost easier to hide, because the bill is spread across graph nodes instead of one visible chat turn. Why can LangGraph handoffs multiply tokens? LangGraph handoffs can multiply tokens because each model-calling node may resend instructions, prior messages, retrieved material, tool returns, summaries, and artifacts, then loops or handoffs repeat that payload for the next agent. Token amplification is the total prompt-plus-completion tokens across a trace divided by a simpler baseline for the same task; Anthropic reported in June 2025 that multi-agent systems used about 15x more tokens than chats while improving an internal research evaluation by 90.2% . Quick Answer: Handoffs raise the token bill when each agent receives copied context instead of a narrow task packet. Anthropic’s June 2025 research system showed the tradeoff clearly: multi-agent runs used about 15x more tokens than chats while scoring 90.2% higher on its internal research evaluation . In LangGraph, the practical issue is observability and budgeting, not whether graphs are bad. The LangGraph project describes the runtime as a way to build stateful, long-running agents with persistence, human control, memory, and debugging support; those same traits make it possible to measure where context grows instead of guessing. "Multi-agent systems are often highly effective at open-ended research tasks, but token usage can be substantial," — Anthropic engineering team at Anthropic The small verified demo below shows the arithmetic behind a 15x bill: a 100-token task becomes 1,500 billed tokens when 5 agents each receive 3 copies of the relevant context . """ Tiny token-accounting demo: handoffs multiply the same task context. """ task_tokens = 100 agents = 5 context_copies_per_handoff = 3 # instructions + task + summary/history direct_bill = task_tokens handoff_bill = task_tokens * agents * context_copies_per_handoff print ( f

What to know about python static file security when using StayPresent's web.html/markdown — directory exposure, path traversal, and URL filtering. Security Notes for Serving Static Files with StayPresent Serving a status dashboard or a rendered README with web.html() / web.markdown() is convenient precisely because it automatically picks up neighboring CSS, JS, and images with no extra configuration. That same convenience has a security dimension worth understanding clearly before you point it at a directory. This covers python static file security as it applies specifically to StayPresent: what's protected automatically, and what's still your responsibility to manage. Table of Contents The Directory-Wide Exposure Behavior Why This Is Intentional Path Traversal Protection The One-Time Directory Warning Markdown-Specific Protections: Escaping Markdown-Specific Protections: URL Scheme Filtering What's Rejected vs What's Allowed Structuring Directories Safely Full Example Best Practices Common Mistakes FAQs Conclusion The Directory-Wide Exposure Behavior When you call web.html("templates/index.html") or web.markdown("docs/guide.md") , StayPresent doesn't just serve that one file — it serves every file in that file's directory , not only the specific CSS/JS/image files actually referenced from the page. This is what makes relative asset links ( href="style.css" , src="images/logo.png" ) work automatically without any extra configuration on your part. The consequence: if a .env file, your bot's own source code, or a .git/ directory happens to sit in that same directory, it becomes downloadable by anyone who requests it by name — whether or not anything on the page actually links to it. templates/ ├── index.html ├── style.css <- intentionally public, referenced from index.html ├── .env <- NOT referenced anywhere, but still reachable Why This Is Intentional This isn't an oversight — it's what makes web.html() / web.markdown() usable with zero configuration for the overwhel

A guide to python isolated logging with StayPresent's dedicated logger — no root logger mutation, what gets logged, and how to configure it. How StayPresent's Logging Works (Without Breaking Yours) A surprisingly common way for a third-party package to quietly break your application's logging is by calling logging.basicConfig() somewhere in its own code — which mutates the root logger and can silently change formatting, duplicate output, or override handlers you already configured for your own loggers. StayPresent avoids this entirely through python isolated logging : everything it logs goes through its own dedicated logger, never the root one. Table of Contents The Problem with logging.basicConfig() StayPresent's Dedicated Logger What Gets Logged, and at What Level Adjusting Verbosity Attaching Your Own Handler Logging During Multi-Bot Runs Logging During Shutdown Full Example Best Practices Common Mistakes FAQs Conclusion The Problem with logging.basicConfig() logging.basicConfig() configures the root logger, which every other logger in your process falls back to unless it's explicitly configured otherwise. If your bot calls it once at startup, and a dependency somewhere else in your stack calls it again, whichever call happens first usually "wins" silently — no error, just unexpected formatting or duplicate log lines that are hard to trace back to their cause. A well-behaved library avoids touching the root logger at all, and instead logs through its own named logger. StayPresent's Dedicated Logger StayPresent logs exclusively through a logger named "staypresent" , configured with a single dedicated StreamHandler and logger.propagate = False . It never calls logging.basicConfig() , and it never touches the root logger in any way. This means it cannot clobber, duplicate, or reformat log output your own script has already configured for its own, unrelated loggers — StayPresent's logs and your bot's logs coexist without interfering with each other. What Gets Logged,

Does it still make sense to learn how to code? This is a question I’ve been thinking about a lot...

Embedding a browser game looks simple: <iframe src= "https://games.example.net/my-game" ></iframe> That line lets a third party join the page lifecycle immediately. It can download a large bundle, establish connections, run scripts, request storage, display advertising, or fail before the visitor decides to play. AI-assistance disclosure: I used AI to help draft and edit this article, then reviewed its architecture, code, claims, and limitations before publication. For a game directory, that default is both expensive and surprising. A visitor may have opened the page to read the controls, compare games, or check whether the game works on a phone. Loading the player before that intent is known wastes bandwidth and collapses two separate decisions—visiting the guide and opening the third-party game—into one. While working on a browser-game portal, I treated the site and the embedded player as two different trust and performance boundaries. The page renders first-party information immediately. The third-party frame is created only after an explicit Play action. This article explains that pattern and the engineering details that made it useful rather than merely decorative. Start with a two-layer model The outer page should be a complete page without the game: A descriptive heading and summary Controls and gameplay tips Developer and platform information Related games and category navigation A poster or cover image A real button that starts the player The inner layer is a small launcher responsible for the game lifecycle: Validate the requested game. Wait for an intentional Play action. Create the provider iframe. Report loading state. Offer recovery when loading is slow or blocked. Remove the frame when the player resets it. Do not put the remote URL in the initial markup Native iframe lazy loading is helpful below the fold, but it is not an intent gate. Browsers decide when a loading="lazy" frame is close enough to fetch. If the goal is “no third-party game request be

Let's Encrypt issues TLS certificates with a 90-day validity period by default. However, as the industry is gradually shortening TLS certificate lifetimes—with the maximum eventually expected to fall to 47 days—Let's Encrypt already offers certificates using the tlsserver profile with a validity period of 45 days. Compared with the current default classic profile, the tlsserver profile removes deprecated attributes such as the Common Name. Because it follows the latest recommended configuration, it also produces slightly smaller certificates. The differences between the profiles are documented on the following page. If you have already automated certificate issuance and renewal, it is worth considering an early move to the tlsserver profile. Certificate Profiles - Let's Encrypt Certificates issued with the classic profile are currently valid for 90 days. However, the validity period is scheduled to be shortened to 64 days in February 2027 and then to 45 days in February 2028. Certificate renewal automation is easy to leave untouched once it is working, and many monitoring systems also use fixed day-based thresholds. Both renewal automation and monitoring therefore require careful review. Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt With only about six months remaining before the validity period is reduced to 64 days, now is a good time to begin validating your systems. Let's Encrypt also provides the shortlived profile for certificates that support IP addresses. These certificates are valid for only six days. With such a short lifetime, using them without automation is no longer practical. 6-Day and IP Address Certificates - Let's Encrypt To issue certificates using any of these profiles, you need an ACME client that supports ACME profile selection. Widely used clients such as Certbot should be able to issue them without difficulty. Issuing a certificate with the new tlsserver or shortlived profile is straightforward. The harder part is keeping it ren

The first version of a webhook is always the same four lines: await fetch(customer.webhookUrl, { ...