diff --git a/2026/2026-09-07.md b/2026/2026-09-07.md
new file mode 100644
index 0000000..8f72160
--- /dev/null
+++ b/2026/2026-09-07.md
@@ -0,0 +1,173 @@
+# Hyperlight 2026-09-07
+
+## Attendees
+
+- Yosh Wuyts
+- Jorge Prendes
+- Tomasz Andrzejak
+- Magnus Kulke
+- Doru Blânzeanu
+- Lucy Menon
+
+## Announcements
+
+## [Roadmap](https://github.com/orgs/hyperlight-dev/projects/2/views/4)
+
+- Hyperlight 0.18.0 on ~2026-10-05
+
+## Meta
+
+Jorge: one of the things discussed last week was the serialization work; one of the things discussed was virtio merged first, and then we're going to focus on serialization. Do we want it in for any particular release?
+
+Tomasz: if we are targeting virtio in 0.18, it would make sense to target serialization for 0.19. Both changes are big enough to not mash them into a single release.
+
+Yosh: makes sense to me
+
+Jorge: another thing I'd like in Hyperlight. When planning snapshotting and OCI images, we discussed layered OCI images. For the work of substrate in Hyperlight, I know there are many possible implementations, maybe we can have something functional that has some of the benefits.
+
+Lucy: I've spoken with Ludvig to get there. Esp. the first iteration of it, shouldn't be much work to get there. Should be a pretty small change overall. I thought Ludvig was the one to work on that. Not sure about his timeline etc. Will see how that is for timeline. Probably can slot that in with other releases.
+
+Jorge: was thinking: can do a memcompare between the two memories and track dirty pages, but that would be more difficult.
+
+Lucy: we already have that info by tracking what is copied in the scratch region. Should be a pretty minor change. Same as right now, we leave out what is in the snapshot image.
+
+Jorge: nice, thank you
+
+Jorge: related to that: we currently have a heap memory, the idea would be to deprecate the heap memory.
+
+Lucy: starting the heap memory with a bunch of zeroed-out pages is useless. Right now it's completely useless zero pages.
+
+Jorge: two levels of deprecation we can do right now; scratch region, the other is a dynamically sized heap.
+
+Lucy: three options
+
+1. keep the current thing with a fixed-size heap but change to allocate pages in it on demand
+2. keep the same allocator we're using but change the support code to make the allocator dynamically sized
+3. actually change the allocator with a nicer design
+
+Jorge: for the C API we're using picolibc which comes with an allocator. Maybe we can reuse some of its APIs?
+
+Lucy: the situation we had last time with this, security folks would prefer we use snmalloc or mimalloc (?) which are security-oriented. Back at the time our PA and VA spaces were very tightly coupled, so the minimum VA space needed for mimalloc was a problem. Our existing LockedHeap allocator in Rust is not good; almost anything we have would be better. But we should bench anything before we switch.
+
+Jorge: the good news is that [...]
+
+Tomasz: if we use the picolibc allocator it would be interesting to reduce the dependencies. picolibc is currently optional, this would make it required.
+
+Tomasz: question about the heap region: currently we are preserving the whole region in the snapshot. Right now the walker is going through the whole region. Are we thinking about granularity here? Are we thinking about which pages are used during the snapshot, or are we fine?
+
+Lucy: all of the upstream items I mentioned earlier reduce the amount of VA space / PA space. Once you've allocated memory the first time, it's hard to reduce memory later on because of fragmentation. We could maybe analyze allocator tracking structures on snapshot to see whether any only contain freed memory and can be discarded, but that would be for much later.
+
+Tomasz: performance?
+
+Lucy: you already have to fault and copy up to the scratch region on the first write to the heap region, so if anything you could potentially get rid of copying those zeroes.
+
+Tomasz: are we thinking about sanitizing parts of the memory?
+
+Lucy: that would be a performance overhead and wouldn't help with security I think. We might be able to add memory compression to Hyperlight, which gives us grief right now. But it wouldn't be something I would look at.
+
+Jorge: except that we could merge pages which are not used, right? If pages are close to each other; trailer of one page, merge it with adjacent pages and skip the whole page?
+
+Lucy: because there is an allocation for that page, you need the memory for the page somewhere?
+
+Jorge: one of the things mentioned is all of the heap is checked into the snapshot; we check if pages are all-zeroes now, which helps with perf.
+However, that doesn't help with the process binary, in cases like Python, where that is constant but not part of the heap. Same for hyperlight-wasm, loading the module is a diff on top of a wasmtime base init image.
+
+Lucy: that is the same justification as for layered snapshots, which Ludvig is working on.
+
+Tomasz: the heap improvements are similar to the virtio buffer improvements. To optimize virtio on the guest, there might be overlap. To retain the buffer that virtio is using, I have a pool of buffers. I can reach out to the virtio state and see which buffers are used by the guest. This way I can have buffer granularity to retain the guest state. It seems like the heap could also benefit from that?
+
+Lucy: the right way would be to have scratch-VA outside of the address space that we map to. Yes, the same abstraction for tracking, but unsure whether there is much that we could share between the two.
+
+Lucy: in the heap there will be spaces that need to be freed, but we don't know what in the code is actually a pointer to it. Depends on how the problem is solved to use a copying garbage collector.
+
+Yosh: pointer provenance?
+
+Lucy: having that info is a pre-req to have the info that I'm talking about in heap-maps. From static info through codegen and heap layout to walk the heap. Can't do that without a memory walk of the objects in the normal case.
+
+Lucy: I thought there was not much appetite to get heap-maps in Rust, but maybe?
+
+Yosh: I can talk to Oli
+
+Lucy: most of the systems which do snapshot/restore do what we do at page granularity, at least for a language like Rust or C, but if you can free up stuff at sub-page granularity it might be worth taking a look at.
+
+Tomasz: regarding our current page allocator, does it allocate physical pages, that is returning the GPA (?) from the scratch region? If we are going to reuse the snapshot walker, we're going to need to alias it to memory outside the allocator. But we should probably keep around the aliases to see if the memory is still being reserved.
+
+Lucy: once the buffer is used and owned by the guest [...]
+
+Tomasz: you still need to remember which region is being used again to restore.
+
+Lucy: for our use cases it's fine to use a bump allocator. We're not going to run out of VA space.
+
+Lucy: can see how Linux does allocations. mmap allocates regions progressively in a way that is a little like our bump allocators for a while. They have this data structure called a maple tree that they use to efficiently track the used address space, but I think something like that is overkill for Hyperlight.
+
+## Triage
+
+### Plumb `max_guest_log_level` through `MultiUseSandbox::from_snapshot` ([#1699](https://github.com/hyperlight-dev/hyperlight/pull/1699))
+
+### Add method for recreating unrecoverable sandbox ([#1751](https://github.com/hyperlight-dev/hyperlight/pull/1751))
+
+### Do not auto-approve dependabot PRs, and add cooldown to dependabot ([#1564](https://github.com/hyperlight-dev/hyperlight/pull/1564))
+
+### Retain page table root finder for in-memory snapshots ([#1730](https://github.com/hyperlight-dev/hyperlight/pull/1730))
+
+### Make ELF loading respect program header virtual addresses for non-PIE binaries ([#1530](https://github.com/hyperlight-dev/hyperlight/pull/1530))
+
+### feat: enable ASLR for PIE guest binaries ([#1655](https://github.com/hyperlight-dev/hyperlight/pull/1655))
+
+### Benchmark prs ([#1529](https://github.com/hyperlight-dev/hyperlight/pull/1529))
+
+### feat: implement virtio based host-guest communication ([#1717](https://github.com/hyperlight-dev/hyperlight/pull/1717))
+
+### feat: macOS support via Hypervisor.framework (aarch64) ([#1681](https://github.com/hyperlight-dev/hyperlight/pull/1681))
+
+### Add a scratch-backed user data region for host/guest byte exchange ([#713](https://github.com/hyperlight-dev/hyperlight/pull/713))
+
+### feat(aarch64): add WHP backend for ARM64 Windows ([#1638](https://github.com/hyperlight-dev/hyperlight/pull/1638))
+
+### Implement MSHV aarch64 backend ([#1626](https://github.com/hyperlight-dev/hyperlight/pull/1626))
+
+### Fix duplicate guest trace batches ([#1619](https://github.com/hyperlight-dev/hyperlight/pull/1619))
+
+### Add unit test for kvm/mshv/whp ([#1106](https://github.com/hyperlight-dev/hyperlight/pull/1106))
+
+### [DO NOT MERGE] swap flatbuffers with serde ([#1158](https://github.com/hyperlight-dev/hyperlight/pull/1158))
+
+### Compile test hyperlight guests in CI ([#1776](https://github.com/hyperlight-dev/hyperlight/issues/1776))
+
+### Heuristic-based scratch zeroing strategy for snapshot restore ([#1766](https://github.com/hyperlight-dev/hyperlight/issues/1766))
+
+### Consider renaming files named `mod.rs/x86_64.rs/aarch64.rs` to more unique filenames ([#1762](https://github.com/hyperlight-dev/hyperlight/issues/1762))
+
+### Add API to create a Snapshot without going through creating a VM partition ([#1755](https://github.com/hyperlight-dev/hyperlight/issues/1755))
+
+### Add API to "replace this sandbox with a new one with the same configuration" ([#1747](https://github.com/hyperlight-dev/hyperlight/issues/1747))
+
+### maintainer PRs still require manual approval of workflow ([#1731](https://github.com/hyperlight-dev/hyperlight/issues/1731))
+
+### Consider setting the default commit message to the PR title and description ([#1708](https://github.com/hyperlight-dev/hyperlight/issues/1708))
+
+### RUSTSEC-2026-0173: proc-macro-error2 is unmaintained ([#1599](https://github.com/hyperlight-dev/hyperlight/issues/1599))
+
+### Allow resizing scratch region ([#1767](https://github.com/hyperlight-dev/hyperlight/issues/1767))
+
+### Snapshot follow up items ([#1479](https://github.com/hyperlight-dev/hyperlight/issues/1479))
+
+### Evaluate serde instead of flatbuffer ([#1607](https://github.com/hyperlight-dev/hyperlight/issues/1607))
+
+### Fully Implement ASLR ([#199](https://github.com/hyperlight-dev/hyperlight/issues/199))
+
+### Add architecture-independent exception handling APIs sufficient for hyperlight-wasm ([#1690](https://github.com/hyperlight-dev/hyperlight/issues/1690))
+
+### Cleanup the hyperlight-host public API ([#765](https://github.com/hyperlight-dev/hyperlight/issues/765))
+
+### Snapshot-First Sandbox Lifecycle ([#1268](https://github.com/hyperlight-dev/hyperlight/issues/1268))
+
+### Track Performance ([#593](https://github.com/hyperlight-dev/hyperlight/issues/593))
+
+### Weekly Coverage Failure - 23 ([#1522](https://github.com/hyperlight-dev/hyperlight/issues/1522))
+
+### WASI HTTP Implementation ([#564](https://github.com/hyperlight-dev/hyperlight/issues/564))
+
+### Guest debugging improvements ([#501](https://github.com/hyperlight-dev/hyperlight/issues/501))
+
+### Combine ReturnValue and ParameterValue into one ([#434](https://github.com/hyperlight-dev/hyperlight/issues/434))