[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-portainer-docker-standalone-upgrade-checklist-en":3,"article-related-portainer-docker-standalone-upgrade-checklist-en":30,"series-tools-4fb85167-2ea8-49c7-bc45-6f94b51526a6":81},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"4fb85167-2ea8-49c7-bc45-6f94b51526a6","portainer-docker-standalone-upgrade-checklist-en","Portainer’s upgrade doc turns Docker updates into a checklist","\u003Cp data-speakable=\"summary\">Portainer’s upgrade flow becomes a copy-ready \u003Ca href=\"\u002Ftag\u002Fdocker\">Docker\u003C\u002Fa> checklist.\u003C\u002Fp>\u003Cp>I’ve been using Portainer on Docker long enough to know the upgrade story can get weird fast. Not because the commands are hard. They aren’t. It’s because the docs make you mentally juggle three things at once: keep the data, replace the container, and don’t accidentally break the \u003Ca href=\"\u002Ftag\u002Fagent\">agent\u003C\u002Fa> side while you’re at it. That’s the part that usually makes people hesitate. You stare at the old container, wonder if a \u003Ccode>docker rm\u003C\u002Fcode> is going to nuke your stack, and then you start second-guessing the whole update. I’ve done that dance. More than once.\u003C\u002Fp>\u003Cp>What I like about Portainer’s \u003Ca href=\"https:\u002F\u002Fdocs.portainer.io\u002Fstart\u002Fupgrade\u002Fdocker\">Docker Standalone upgrade doc\u003C\u002Fa> is that it’s blunt. Stop the old container. Remove it. Pull the new image. Run the new container against the same volume. Done. But there are a few sharp edges buried in the text: version matching between server and agents, the 1.x-to-2.0 hop, HTTPS on 9443, and the fact that the agent update is its own little ritual. That’s where people get burned, not in the main upgrade command.\u003C\u002Fp>\u003Ch2>Portainer’s real trick is boring on purpose\u003C\u002Fh2>\u003Cblockquote>To update to the latest version of Portainer Server, use the following commands to stop then remove the old version. Your other applications\u002Fcontainers will not be removed.\u003C\u002Fblockquote>\u003Cp>What this actually means is: Portainer is designed to be disposable as a container, but not disposable as data. The container goes away. The volume stays. That distinction matters more than the fancy UI ever will.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780915699932-pr2l.png\" alt=\"Portainer’s upgrade doc turns Docker updates into a checklist\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>I’ve seen teams treat container upgrades like surgery when they’re really closer to swapping a battery. If your configuration lives in a named volume like \u003Ccode>portainer_data\u003C\u002Fcode>, the update path is just a replace operation. The doc is quietly teaching you a pattern I wish more tools would use: make the runtime ephemeral, keep state external, and make the upgrade path obvious.\u003C\u002Fp>\u003Cp>Here’s the practical takeaway. If you’re running Portainer the recommended way, you should be able to stop and remove the container without touching your apps. The only thing that changes is the Portainer process itself. That’s the whole point of using Docker here. If your workflow depends on “don’t ever delete the container,” you’re already in trouble.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Confirm Portainer data is stored in a named volume, not inside the container filesystem.\u003C\u002Fli>\u003Cli>Use \u003Ccode>docker stop\u003C\u002Fcode> and \u003Ccode>docker rm\u003C\u002Fcode> only for the Portainer container, not your application stacks.\u003C\u002Fli>\u003Cli>Keep a backup anyway. I don’t care how confident you feel.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you want the source, this is all coming from Portainer’s own upgrade page, not from some random blog post that guessed at the commands.\u003C\u002Fp>\u003Ch2>Version matching is the part people skip, then regret\u003C\u002Fh2>\u003Cp>The doc says to always match the agent version to the Portainer Server version. If you’re on 2.39.3, your agents should also be on 2.39.3. That sounds fussy until you’ve had a server talking to an older agent and started getting odd behavior that looks like networking but is really version drift.\u003C\u002Fp>\u003Cp>What this actually means is that Portainer is not giving you a loose compatibility promise here. It wants the server and agents aligned. I get why people ignore this. In a lot of tooling, “close enough” works. Here, close enough is how you end up debugging a problem that isn’t really a problem in Docker at all. It’s a mismatch.\u003C\u002Fp>\u003Cp>I ran into this pattern in a small lab setup where the server got updated first and the agents lagged behind. Nothing exploded. That’s the annoying part. It just got flaky enough to waste my afternoon. The doc is doing you a favor by being explicit: don’t treat the agent as an afterthought.\u003C\u002Fp>\u003Cp>There’s also the migration warning for people still on 1.x. You have to go to 2.0.0 first before jumping to the newest version. That’s not a suggestion. It’s a path dependency. Skip it and you can run into issues that are much harder to unwind than just following the boring step.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Check the current server version before upgrading anything else.\u003C\u002Fli>\u003Cli>Upgrade agents in lockstep with the server when possible.\u003C\u002Fli>\u003Cli>If you’re on Portainer 1.x, plan a two-step upgrade, not a leap.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For more context, Portainer keeps the upgrade docs split by platform, which is exactly what I’d expect from something that has to support Docker, Swarm, Podman, Kubernetes, and Nomad without pretending they’re the same thing.\u003C\u002Fp>\u003Ch2>Don’t ignore the HTTPS shift on 9443\u003C\u002Fh2>\u003Cp>The docs call out a detail that matters more than it looks: starting from Portainer CE 2.9 and BE 2.10, HTTPS is enabled by default on port 9443. The update commands are written for that world. They do not expose 9000 for HTTP unless you add it yourself.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780915693101-3yx9.png\" alt=\"Portainer’s upgrade doc turns Docker updates into a checklist\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>What this actually means is that if your old setup was built around plain HTTP, the upgrade can feel like Portainer changed the rules on you. It didn’t. It changed the default posture. That’s a good thing, but only if your agents and edge agents are already talking HTTPS before you flip the switch.\u003C\u002Fp>\u003Cp>I’ve seen people update Portainer and then discover their browser bookmark still points at \u003Ccode>http:\u002F\u002Fserver:9000\u003C\u002Fcode>. Then they assume the service is down. It isn’t. They just didn’t follow the new port and protocol expectations. This is exactly the kind of detail that gets buried when you skim docs and copy only the container command.\u003C\u002Fp>\u003Cp>There’s also a practical note in the doc: if you need to retain HTTP access, you can add \u003Ccode>-p 9000:9000\u003C\u002Fcode>. That’s useful during a transition, but I’d treat it as temporary. If you’re already moving to HTTPS, keep the old port only as long as you need it.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Verify your agents and edge agents are already using HTTPS before updating the server.\u003C\u002Fli>\u003Cli>Use port 9443 as the main access point after the upgrade.\u003C\u002Fli>\u003Cli>Only keep port 9000 open if you have a real reason, not because the old habit feels comfortable.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Portainer also documents custom SSL certificate flags, which matters if you don’t want to rely on the defaults. That’s the sort of thing I appreciate when I’m trying to keep a homelab or internal platform from turning into a certificate scavenger hunt.\u003C\u002Fp>\u003Ch2>The update is really a replace-and-reuse move\u003C\u002Fh2>\u003Cp>The server update sequence is simple: stop the container, remove it, pull the latest image, run a new container with the same named volume. The doc even says your other applications and containers will not be removed. That sentence is doing a lot of work.\u003C\u002Fp>\u003Cp>What this actually means is that the upgrade is not a migration. It’s a container replacement using persistent storage. That’s the mental model I wish every ops doc used, because it removes the drama. You are not “upgrading the system” in the abstract. You are swapping the runtime and keeping the state.\u003C\u002Fp>\u003Cp>Here’s the core flow in plain English:\u003C\u002Fp>\u003Cul>\u003Cli>Stop Portainer.\u003C\u002Fli>\u003Cli>Remove the old container.\u003C\u002Fli>\u003Cli>Pull the latest \u003Ccode>lts\u003C\u002Fcode> image.\u003C\u002Fli>\u003Cli>Run the new container with the same volume and ports.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>The images matter too. Portainer gives separate references for Business Edition and Community Edition, both using the \u003Ccode>lts\u003C\u002Fcode> tag in the doc. That tells me they want you on a stable channel, not chasing every tiny release. Good. I prefer that for admin tooling anyway.\u003C\u002Fp>\u003Cp>I’ve had better results when I treat admin dashboards like infrastructure, not apps. I don’t want surprise behavior in the tool I use to manage everything else. So yes, I want the stable tag. Yes, I want the same volume. And yes, I want the upgrade to be boring.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Use the exact edition image that matches your installation: \u003Ccode>portainer-ce\u003C\u002Fcode> or \u003Ccode>portainer-ee\u003C\u002Fcode>.\u003C\u002Fli>\u003Cli>Keep the named volume unchanged so Portainer can reuse its database.\u003C\u002Fli>\u003Cli>Pull the image before the run step so you know what’s actually on disk.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you’re curious, the official docs also point to the broader Portainer docs site at \u003Ca href=\"https:\u002F\u002Fdocs.portainer.io\u002F\">docs.portainer.io\u003C\u002Fa>, which is where I’d go when I need the platform-specific variations instead of guessing.\u003C\u002Fp>\u003Ch2>The agent update is its own mini-procedure\u003C\u002Fh2>\u003Cp>Portainer’s agent-only update path is separate, and that’s exactly how it should be. Stop the old agent container, remove it, pull the new \u003Ccode>portainer\u002Fagent:lts\u003C\u002Fcode> image, then run it again. The doc also reminds you that if you set a custom \u003Ccode>AGENT_SECRET\u003C\u002Fcode> on the server, you need to pass the same secret to the agent when you update it.\u003C\u002Fp>\u003Cp>What this actually means is that the agent is not just a sidecar you can casually replace without checking the server config. It has an identity. If you configured a secret, that secret is part of the handshake. Forget it and you’ll spend time looking at connection failures that are really just missing environment variables.\u003C\u002Fp>\u003Cp>I like that the doc calls out the secret explicitly, because this is the kind of thing people forget at 11 p.m. when they’re trying to “just refresh the agent.” Then they wonder why the server can’t see the environment. Been there. The fix is not exciting. It’s just precise.\u003C\u002Fp>\u003Cp>There’s also a port reminder here: the agent example uses port 9001. If you’re putting this behind a firewall or on a stricter network, that’s the port to keep in mind. It’s easy to focus on the server’s 9443 and forget the agent has its own exposure.\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Update agents separately from the server if needed, but keep versions aligned.\u003C\u002Fli>\u003Cli>Carry over \u003Ccode>AGENT_SECRET\u003C\u002Fcode> whenever you use one.\u003C\u002Fli>\u003Cli>Check port 9001 access if the agent is meant to be reachable from Portainer.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>For the record, Portainer’s docs also link to their broader support and community channels, including GitHub at \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fportainer\u002Fportainer\">github.com\u002Fportainer\u002Fportainer\u003C\u002Fa>, which is where I’d look if I needed to compare real-world issues against the documented path.\u003C\u002Fp>\u003Ch2>Why the backup warning is the least optional line in the doc\u003C\u002Fh2>\u003Cp>The page recommends backing up your current Portainer configuration before any update. That line is easy to skim past because the commands look safe. They mostly are. But “mostly” is not a backup strategy.\u003C\u002Fp>\u003Cp>What this actually means is that the upgrade path is low-risk if you’ve already treated Portainer like a stateful service with recoverable metadata. If not, the backup is the thing that turns a bad upgrade from a disaster into an inconvenience.\u003C\u002Fp>\u003Cp>I’m pretty opinionated about this one. Any admin tool that controls containers, stacks, registries, and environments should get backed up before version changes. Not because Portainer is fragile, but because your operational memory is. You will forget a flag. You will forget a custom cert path. You will forget some little tweak that made the setup work six months ago.\u003C\u002Fp>\u003Cp>So the doc’s backup line is not decorative. It’s the difference between “I can restore this” and “I guess I’m reconstructing the setup from screenshots and memory.”\u003C\u002Fp>\u003Cp>How to apply it:\u003C\u002Fp>\u003Cul>\u003Cli>Back up the Portainer data volume before the upgrade.\u003C\u002Fli>\u003Cli>Record custom flags used in the original container run command.\u003C\u002Fli>\u003Cli>Save the current image tag and version so rollback is possible.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you want the cleanest mental model, think of the upgrade as: preserve data, replace runtime, verify access, then confirm the version changed. That’s it. No ceremony required.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Portainer Docker Standalone upgrade checklist\n\n## Before you start\n- [ ] Confirm current Portainer version\n- [ ] Confirm whether you're on CE or BE\n- [ ] Back up the Portainer data volume\n- [ ] Confirm agents are on the same version as the server\n- [ ] If upgrading from 1.x, plan a hop to 2.0.0 first\n- [ ] Confirm HTTPS\u002F9443 is already working for agents and edge agents\n\n## Upgrade Portainer Server\n# Stop and remove the old container\ndocker stop portainer\ndocker rm portainer\n\n# Pull the correct edition image\n# Community Edition:\ndocker pull portainer\u002Fportainer-ce:lts\n\n# Business Edition:\n# docker pull portainer\u002Fportainer-ee:lts\n\n# Start the updated container\n# Community Edition:\ndocker run -d -p 8000:8000 -p 9443:9443 --name=portainer --restart=always \\\n  -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n  -v portainer_data:\u002Fdata \\\n  portainer\u002Fportainer-ce:lts\n\n# Business Edition:\n# docker run -d -p 8000:8000 -p 9443:9443 --name=portainer --restart=always \\\n#   -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n#   -v portainer_data:\u002Fdata \\\n#   portainer\u002Fportainer-ee:lts\n\n## Optional flags\n# Keep HTTP open during transition\n# -p 9000:9000\n\n# Use custom TLS certificates\n# --sslcert \u002Fpath\u002Fto\u002Fcert\u002Fportainer.crt \\\n# --sslkey \u002Fpath\u002Fto\u002Fcert\u002Fportainer.key\n\n## Update Portainer Agent\n# Stop and remove the old agent\n# docker stop portainer_agent\n# docker rm portainer_agent\n\n# Pull the agent image\n# docker pull portainer\u002Fagent:lts\n\n# Start the agent\n# docker run -d -p 9001:9001 --name portainer_agent --restart=always \\\n#   -v \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock \\\n#   -v \u002Fvar\u002Flib\u002Fdocker\u002Fvolumes:\u002Fvar\u002Flib\u002Fdocker\u002Fvolumes \\\n#   portainer\u002Fagent:lts\n\n# If you use a custom AGENT_SECRET, include it here:\n#   -e AGENT_SECRET=yoursecret\n\n## After the update\n- [ ] Open https:\u002F\u002Fyour-server-address:9443\n- [ ] Confirm the update notification is gone\n- [ ] Confirm the version number changed\n- [ ] Confirm environments and agents are connected\n- [ ] Confirm any custom certificates still load correctly\n- [ ] If needed, remove temporary HTTP exposure on 9000\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>That checklist is my distilled version of Portainer’s own Docker Standalone upgrade page, with the moving parts separated so you can actually use it under pressure. The official doc is at \u003Ca href=\"https:\u002F\u002Fdocs.portainer.io\u002Fstart\u002Fupgrade\u002Fdocker\">https:\u002F\u002Fdocs.portainer.io\u002Fstart\u002Fupgrade\u002Fdocker\u003C\u002Fa>. My template is derivative of that source, but the checklist layout and operational framing are mine.\u003C\u002Fp>\u003Cp>If you want the cleanest path, copy the template, swap in your edition, and keep the agent version in lockstep with the server. That’s the whole upgrade story, minus the unnecessary drama.\u003C\u002Fp>","I break down Portainer’s Docker Standalone upgrade flow into a copy-ready checklist you can reuse without guessing.","docs.portainer.io","https:\u002F\u002Fdocs.portainer.io\u002Fstart\u002Fupgrade\u002Fdocker",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780915699932-pr2l.png","tools","en","eaafcfeb-80da-44b6-9b20-06e9846d52a5",[17,18,19,20,21],"Portainer","Docker","upgrade","agents","HTTPS",[23,24,25],"Portainer upgrades are container replacement, not data migration.","Server and agent versions need to stay aligned.","The HTTPS and AGENT_SECRET details are where most upgrade mistakes happen.",0,"2026-06-08T10:47:47.814734+00:00","2026-06-08T10:47:47.799+00:00","4d4cbab5-9bf7-4659-8d0c-a90686cb3943",{"tags":31,"relatedLang":40,"relatedPosts":44},[32,34,35,36,38],{"name":21,"slug":33},"https",{"name":20,"slug":20},{"name":19,"slug":19},{"name":17,"slug":37},"portainer",{"name":18,"slug":39},"docker",{"id":15,"slug":41,"title":42,"language":43},"portainer-docker-standalone-upgrade-checklist-zh","Portainer 升級文把 Docker 更新變清單","zh",[45,51,57,63,69,75],{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"38d3abd2-573b-4755-b9b7-b149bf7bb899","rust-worth-the-hype-2026-right-jobs-en","Rust is worth the hype in 2026, but only for the right jobs","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780921974191-8fed.png","2026-06-08T12:32:21.456662+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"e8ef7289-0643-4567-b316-5c2f5cef5d9f","supabase-docker-self-hosting-guide-en","Supabase’s Docker self-hosting guide gets practical","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780916582916-5t5w.png","2026-06-08T11:02:32.314917+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"99bfce29-7722-4619-9537-0c94c15ad5fc","cursor-teams-pricing-adds-96-premium-seat-en","Cursor Teams pricing adds $96 Premium seat","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780909376960-n787.png","2026-06-08T09:02:25.546066+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"a0ebdaf9-3a82-4c5a-9af6-d66ccc860e5e","awesome-ai-summerschool-ai-events-shortlist-en","awesome-ai-summerschool turns AI events into a shortlist","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780905814274-elcy.png","2026-06-08T08:02:47.048945+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"071a2cea-17a5-4c4a-87cc-0d20ed20cbbd","rustup-rust-official-toolchain-installer-en","Rustup is Rust’s official toolchain installer","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780903081166-cox8.png","2026-06-08T07:17:37.744868+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"736107e8-43ea-4213-b251-b1bbce64a7f2","rust-cli-project-5-practical-steps-en","Rust CLI Project in 5 Practical Steps","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1780898582667-xfn1.png","2026-06-08T06:02:31.670073+00:00",[82,87,92,97,102,107,112,117,122,127],{"id":83,"slug":84,"title":85,"created_at":86},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":88,"slug":89,"title":90,"created_at":91},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":123,"slug":124,"title":125,"created_at":126},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":128,"slug":129,"title":130,"created_at":131},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]