The Crystal Programming Language

Releasing Execution Contexts

2026-07-12T00:00:00+00:00

Two and a half years ago, with the invaluable support from 84codes, we re-examined the multithreading model inherited from Crystal 0.28 (preview MT).

There are different ways to spread an application to multiple CPU cores. So far, preview MT proposed a simple solution, and it worked great for many cases, yet sometimes we need more control over where and how a specific piece of code must run.

Sometimes we need a fiber to own a thread, notably GUI and game loops.
Sometimes we need a set of fibers to run concurrently.
Sometimes we need fibers to scale to as many CPU cores as needed.

Inspired by Kotlin contexts, we realized that we didn’t have to pick just one model. What if we designed an interface instead?

Hence came Execution Contexts. Plural, because there are multiple ways to orchestrate fibers across one to many threads. Ultimately we plan to make the interface public, so you may write your own models.

Applications run in a default context that is automatically created on the main thread. It’s a parallel context that defaults to a parallelism of 1, so fibers run concurrently on just one thread. This avoids a breaking change to existing applications that may not be ready for MT.

You can resize the default context to increase parallelism, making it truly parallel, and letting it automatically scale fibers across CPU cores as needed at runtime:

Fiber::ExecutionContext.default.resize(maximum: System.cpu_count)

You can keep it concurrent and start additional contexts to control the execution and let the OS preempt the threads:

parallel = Fiber::ExecutionContext::Parallel.new("MT", maximum: 4)
parallel.spawn { }

You can keep it single-threaded if you don’t need parallelism, or let users determine the parallelism through a --threads N argument.

Your application, your choice.

Execution contexts allow you to start one or many fiber orchestrators to run fibers in different manners. Fibers are tied to their execution context, and the execution of fibers depends on the context they belong to.

We currently provide three different context types:

Concurrent: Fibers spawned into the context run concurrently to each other, and will never run in parallel; they only run in parallel to fibers running in other contexts.
Parallel: Fibers spawned in a parallel context run concurrently and in parallel to each other, in addition to fibers running in other contexts. The context automatically scales to multiple CPU cores, up to the configured maximum.
Isolated: Spawn a single fiber to a system thread. The fiber owns the thread for its whole lifetime. The fiber can block the thread however it wants (it owns it) with no impact on the rest of the application.

Fibers can always communicate and synchronize with any other fibers, regardless of the execution context in which they run. Use Channel and Sync types normally.

Note that cross context communication requires more synchronization than internal communication, and can thus be slower. This is mostly noticeable in extreme situations, notably benchmarks.

Preview MT starts a fixed number of threads and ties each fiber to a single thread on which it is always resumed. You have no control over where a fiber would start aside from “spawn on the current thread of the current fiber”; you can’t isolate a fiber to a thread, plus other limitations.

Fibers can get stuck on one thread busy running a CPU-intensive work, while other threads are idle. A slow getaddrinfo DNS request, for example, might block your whole application from making any progress, or event fail to respond to Ctrl+C or SIGINT to terminate the process.

Execution contexts solve all these issues.

The fiber scheduler has seen a complete overhaul. It is nothing like before. Not only is it faster than the legacy schedulers, including both single thread and preview MT, fibers will now automatically scale to as many CPU cores as needed at runtime.

The CRYSTAL_WORKERS environment variable is no longer used by default. You can use it manually to resize the default context, or start a parallel context. For example:

maximum = ENV["CRYSTAL_WORKERS"]?.try(&.to_i?) || 4
Fiber::ExecutionContext.default.resize(maximum)

We have kept the breaking changes to a minimum and expect most applications to continue running normally by keeping their default context concurrent.

If you experience issues, you may revert to the legacy, single-threaded, scheduler using the without_mt compilation flag.

The preview_mt compilation flag is still supported; using it reverts to the legacy, multi-threaded, preview scheduler.

The -Dpreview_mt -Dexecution_context combinaition of flags is still supported, and won’t revert to the legacy preview MT scheduler.

Warning

You are heavily encouraged to upgrade to execution contexts because we can’t guarantee legacy support will continue in upcoming releases.

If you need the without_mt or preview_mt flag, and it’s unrelated to the below breaking changes, then we consider this to be a bug in the Crystal runtime.

Please report any issues!

Unlike the previous models (single-threaded and preview MT), the execution of Fibers can move to another thread at runtime.

Fibers spawned in a parallel context can be resumed by any thread in the context. Fibers can start on one system thread, wait on I/O or a channel, then be resumed by another thread in the context. This feature is known as work stealing, and allows to scale fibers across CPU cores.

Unlike the previous schedulers (single-threaded and preview MT), the new schedulers can move to another thread at runtime.

A scheduler runs fibers sequentially on a single thread. The previous models kept schedulers tied to their thread, but with execution contexts schedulers can jump to another thread.

This can happen for some specific syscalls, such as getaddrinfo(3) that can block the current thread and thus block the other fibers from progressing. When that happens the scheduler can move to another thread to continue executing runnable fibers while the current thread is blocked on the syscall. When the syscall returns, the fiber is stopped and will eventually be resumed on the new thread.

This applies to both concurrent and parallel contexts, including the default context. It doesn’t apply to the isolated context where blocking the thread is the expected behavior.

We don’t expect many applications to break, unless you rely on external C libraries that expect to keep running on the main thread, or heavily rely on thread locals. In that case, you may backup and restore thread-local state, or consider isolated contexts.

This impacts the preview MT model. The argument is deprecated and the behavior depends on the execution context:

The concurrent execution context simply ignores the same_thread argument (noop).

The parallel execution context ignores same_thread: false (noop), but doesn’t support same_thread: true argument and will raise an exception at runtime because that feature can’t be guaranteed.

The default execution context is parallel, so same_thread: true will raise an exception at runtime, even if you never resize the context to opt in to MT; because the context might be resized in the future.

The isolated context can’t directly spawn fibers, but instead spawns into the default context or another specified context, so the behavior depends on the target context.

If the value for same_thread is set to false you can safely drop the argument.

If set to true, you will have to investigate if there is an actual issue regarding parallelism.

If there is an issue, you can either fix the issue (for example by using Sync primitives), or start a concurrent execution context and spawn the fibers that can’t run in parallel there, or choose to not resize the default context (no parallelism until you opt-in).

In any case, drop the argument.

Auto-scaling roughly occurs every 100 ms, and stems from the idea that there’s no need to spread work until it’s required. Another name for the feature is “slow-parallelism”. While it improves efficiency, it can alter parallelism expectations, especially in benchmarks that may finish before the executable needs to scale to multiple threads. That’s the point of the feature, yet it defeats the point of a benchmark.

Crystal 1.20.3 is released!

2026-07-02T00:00:00+00:00

We are announcing a new Crystal release 1.20.3 with fixes for two security vulnerabilities in the YAML parsers. We recommend upgrading as soon as possible if your application processes YAML files from unknown origins.

See the release notes of 1.20.0 for all the changes introduced in Crystal 1.20.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 2 security fixes and 1 refactor since 1.20.2 by 1 contributor. We thank all the contributors for all the effort put into improving the language! ❤️

The YAML parsers use recursion to parse sequences and mappings but didn’t limit how deep they could be nested. A deeply nested YAML document could lead to stack overflows (#17107).

Add max_nesting to YAML::PullParser (#17107)

Thanks, @ysbaddaden

The YAML parsers were vulnerable to the billion laughs attack when expanding aliases, growing the document from 100 nodes to over 1 billion nodes for example. The parser had no issues parsing the document, but any attempt to walk the stack could walk the same nodes over and over, quickly slowing down applications.

Add alias vs anchor ratio check to YAML::PullParser (#17109)
Memoize anchor name in YAML::PullParser (#17108)

Thanks, @ysbaddaden

For more details, visit the full changelog.

Thanks

We have been able to do all of this thanks to the continued support of 84codes and every other sponsor. To maintain and increase the development pace, donations and sponsorships are essential. OpenCollective is available for that.

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

Post Mortem: HTTP Request Smuggling Vulnerability

2026-05-26T00:00:00+00:00

On 12 April 2026, we received a vulnerability report regarding an HTTP request smuggling vulnerability in HTTP::Server.

The issue was caused by the HTTP request parser prioritizing the Content-Length header over the Transfer-Encoding header, which can lead to desynchronization when a proxy that prioritizes the Transfer-Encoding header sits in front of HTTP::Server for example.

The vulnerability was patched in Crystal 1.20.0 and Crystal 1.19.2, following the mitigation from RFC 9112, Section 6.1 to always reject requests with both headers and to prioritize Transfer-Encoding then close the connection.

2026-04-12: Gabriel Rodrigues reported the vulnerability to security@manas.tech
2026-04-13: The report was shared with the Crystal Core Team and acknowledged to the reporter. The risk was assessed as low by team.
2026-04-15: The patch of choice (rejecting requests with both headers) was confirmed as the mitigation. The reporter was informed about the assessment and mitigation strategy.
2026-04-16: The patch was merged and a security advisory was published. Crystal 1.20.0 was released with the fix.
2026-04-27: Crystal 1.19.2 was released with the backported patch.

The issue resided in the HTTP Request parser, specifically in the parse_headers_and_body method. The method used elsif to connect the checks for Content-Length and Transfer-Encoding, ensuring only one branch would execute. This meant that if Content-Length was present, the Transfer-Encoding branch would never be evaluated, regardless of its value.

elsif content_length = content_length(headers)
  body = FixedLengthContent.new(io, content_length)
elsif headers["Transfer-Encoding"]? == "chunked"
  body = ChunkedContent.new(io)

This behavior wasn’t compliant with the mitigation from RFC 9112, Section 6.1:

A server MAY reject a request that contains both Content-Length and Transfer-Encoding or process such a request in accordance with the Transfer-Encoding alone. Regardless, the server MUST close the connection after responding to such a request to avoid the potential attacks.

A server or client that receives an HTTP/1.0 message containing a Transfer-Encoding header field MUST treat the message as if the framing is faulty, even if a Content-Length is present, and close the connection after processing the message.

An attacker could craft a request like the following (no proxy required for demonstration):

POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked

43
GET /admin HTTP/1.1
Host: example.com

0

This request is ambiguous: Content-Length declares a 4 bytes body (43\r\n) while Transfer-Encoding would start reading. Since HTTP::Server favors Content-Length it would execute the POST / request then continue with the smuggled GET /admin request.

The vulnerability allowed attackers to inject arbitrary HTTP requests into the connection between a reverse proxy and a Crystal HTTP::Server. This could bypass authentication, rate limiting, or access control enforced at the proxy layer for example. However, exploitation required a vulnerable or non-compliant proxy, limiting the practical impact.

Can it be directly exploited? No.
Can it be exploited through a third party? Yes: vulnerable proxy or load balancer.
Are there possible exploits for the software flaw? Yes: CL.TE for example.
Are there known exploits for HTTP::Server + third party? No.
Are there known threats? No.

Risk: low.

The vulnerability stemmed from non-compliance with RFC 9112, which explicitly states that a server should either reject requests with both headers or prioritize Transfer-Encoding to mitigate request smuggling.

HTTP::Server thus now rejects requests with both Content-Length and Transfer-Encoding and the HTTP parser now prioritizes the Transfer-Encoding header before considering Content-Length, aligning with the RFC 9112.

This fix was included in Crystal 1.20.0 and 1.19.2.

RFC Compliance Matters: Adhering to RFCs is critical for security and interoperability. Non-compliance can introduce vulnerabilities, even if they seem theoretical.
Vulnerability in Chains: A vulnerable server may not be at risk, but a bug and a vulnerability in different software can lead to an exploitable attack.
Training: We treated this as a serious issue, even if the practical impact was low, if only to prepare for more severe vulnerabilities in the future.

Thank you Gabriel Rodrigues for reporting this vulnerability!

Crystal 1.20.2 is released!

2026-05-15T00:00:00+00:00

We are announcing a new Crystal release 1.20.2 with a couple of regressions fixed.

See the release notes of 1.20.0 for all the changes introduced in Crystal 1.20.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 2 bug fixes since 1.20.1 by 1 contributor. We thank all the contributors for all the effort put into improving the language! ❤️

This patch release brings the regression fix for Range#sample (#16909) that could eventually lose randomness to the 1.20 release branch. This was previously released as a backport for 1.19 in Crystal 1.19.2 (#16853).

Thanks, @ysbaddaden

For more details, visit the full changelog.

Thanks

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

Crystal 1.20.1 is released!

2026-04-29T00:00:00+00:00

We are announcing a new Crystal release 1.20.1 with a couple of regressions fixed.

See the release notes of 1.20.0 for all the changes introduced in Crystal 1.20.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 9 changes since 1.20.0 by 2 contributors. We thank all the contributors for all the effort put into improving the language! ❤️

Support for Kernel TLS was introduced in 1.20.0 but it showed issues in production. Some have been fixed (#16888) but there are still some problems so it was disabled by default (#16897).

You can opt-in to Kernel TLS by adding the ENABLE_KTLS option:

ssl_context.add_options(OpenSSL::SSL::Options::ENABLE_KTLS)

Thanks, @ysbaddaden

This patch release fixes a regression in Range#sample (#16853) that could eventually lose randomness.

Thanks, @ysbaddaden

For more details, visit the full changelog.

Thanks

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

Crystal 1.19.2 is released!

2026-04-27T00:00:00+00:00

We are announcing a new Crystal release 1.19.2 with two regressions fixed.

See the release notes of 1.19.0 for all the changes introduced in Crystal 1.19.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 3 changes since 1.19.1 by 2 contributors. We thank all the contributors for all the effort put into improving the language! ❤️

HTTP::Server accepted requests containing both Content-Length and Transfer-Encoding headers and prioritized Content-Length. This allowed HTTP request smuggling as per CWE-444 when the server is behind a vulnerable frontend. Refer to the advisory for more details.

HTTP::Server now rejects requests where both headers are present. The HTTP parser now ignores Content-Length when the Transfer-Encoding header is present (commit c948b31).

This patch release fixes a regression in Range#sample (#16866) that could eventually lose randomness.

For more details, visit the full changelog.

Thanks

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

Crystal 1.20.0 is released!

2026-04-16T00:00:00+00:00

We are announcing a new Crystal release 1.20.0 with several new features and bug fixes.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 161 changes since 1.19.1 by 21 contributors. We thank all the contributors for all the effort put into improving the language! ❤️

Below we list the most remarkable changes in the language, compiler and stdlib. For more details, visit the full changelog.

We do not expect any breaking changes in existing code. We expect the few bugfixes below to not negatively impact your programs. If you notice any unexpected issues, please let us know in the issue tracker or forum.

OpenSSL sockets shouldn’t flush on read (#16650)
Fix Process#wait to not close @input before waiting (#16620, #16638)
Ensure that heredoc lexing allows only valid identifiers (#16548)

Thanks @straight-shoota, @ysbaddaden, @Sija

HTTP::Server now rejects requests where both headers are present. The HTTP parser now ignores Content-Length when the Transfer-Encoding header is present. (commit c948b31).

RFC 0020 introduces a new @[TargetFeature] annotation that allows specifying CPU features or a CPU model or variant for individual functions. It complements the --mattr and --mcpu CLI arguments that target the whole program. This allows embedding multiple optimized functions for different CPU features into a single executable, for example a portable SIMD implementation alongside AVX2 and AVX512 alternatives.

The program is responsible for detecting which feature is available and calling the proper function at runtime. Otherwise, the program might crash with SIGILL, for example.

For example:

{% if flag?(:x86_64) %}
  @[TargetFeature("+avx2")]
  private def foo_avx2
  end

  private def cpu_supports_avx2?
  end
{% end %}

private def foo_portable
end

def foo
  {% if flag?(:x86_64) %}
    return foo_avx2 if cpu_supports_avx2?
  {% end %}
  foo_portable
end

While not strictly required, we still recommend wrapping architecture-specific method definitions within macro flag checks.

Add @[TargetFeature] annotation (#16717)

Thanks @stakach

Execution contexts from RFC 0002 continue as a final preview feature, enabled with the compiler flags -Dpreview_mt -Dexecution_context. We plan to enable it by default in Crystal 1.21.

In addition to fixing bugs, we implemented M:N scheduling that allows threads to be attached to and detached from a context. This avoids blocking other fibers on certain syscalls, such as getaddrinfo.

Add Fiber::ExecutionContext::ThreadPool (#15885, #16750)
Detach execution context scheduler from running thread during blocking syscall (#15871, #16679)

The parallel contexts now automatically start threads to adapt to the actual workload and distribute fibers across more cores when needed.

Add adaptive scaling to ExecutionContext::Parallel (#16719)

This effort is part of the ongoing project to improve multi-threading support with the help of 84codes.

Thanks @ysbaddaden

This release brings a new ergonomic, safe, and portable API for spawning sub-processes, as proposed in RFC 0025.

A significant change is that the modern API treats the command line as an array of strings. The first element is the program to execute, and the remaining elements are its arguments.

# legacy API:
Process.run("crystal", ["tool", "format"])

# modern API:
Process.run(["crystal", "tool", "format"])

The new API also includes convenient methods for capturing process output: Process.capture and Process.capture_result.

The new API does not have a shell parameter. If you need shell behaviour, we recommend running a shell explicitly.

These are the most significant individual changes:

Add overloads with combined args parameter instead of command, args (#16681, #16739)
Add Process.run? (#16738)
Add Process.capture (#16773)

All new methods and overloads are experimental. We expect to stabilize the API for the next release.

Thanks @straight-shoota

An io_uring event loop is available for Linux targets and can be selected by specifying -Devloop=io_uring when compiling. The event loop is highly experimental and its performance benefits will differ for every program. We don’t expect it to be faster than epoll, and it may even be slower, except on some benchmarks with SQPOLL enabled.

SQPOLL can be selected by specifying the idle time for the kernel threads with -Dio_uring_sq_thread_idle=200 (for 200ms). It is recommended to keep the idle time low (below 2s), otherwise your CPU cores will regularly spin at 100% usage when doing nothing.

An interesting but potentially surprising behavior is that any I/O call that could yield the calling fiber will now always yield. One benefit is that an always ready socket won’t block other fibers from progressing. A downside is that there might be lots of context switches.

Add io_uring event loop (linux) (#16264)

Thanks @ysbaddaden

Note

Kernel TLS is opt-in since 1.20.1 due to unresolved issues.

Kernel TLS is now supported by default on Linux and FreeBSD as long as support has been compiled into OpenSSL (which should be the default) and enabled on the system (likely disabled by default), for example with modprobe tls on Linux.

Add Kernel TLS support to custom OpenSSL::BIO (#16646)

Thanks @ysbaddaden

Add #select and #reject to HashLiteral and NamedTupleLiteral (#16558)
Refine error message for unsupported named arguments in macros (#16576)

Thanks @Blacksmoke16, @hahwul

OptionParser now supports option bundling and can parse -ncfoo as -n -c foo.

Add short option bundling for OptionParser (#16770)

Thanks @Qard

The OAuth module expected a success response on HTTP OK statuses, but multiple OAuth providers send error responses with an HTTP OK status (sic).

Detect OAuth error in payload (#16634)

Thanks @jgaskins

HTTP::WebSocket can now negotiate sub-protocols.

Add Sec-WebSocket-Protocol checks to HTTP::WebSocket::Protocol (#16600, #16671)
Add support for Sec-WebSocket-Protocol to HTTP::WebSocketHandler (#16574)

Thanks @antondalgren, @straight-shoota

StringScanner saw multiple improvements, ranging from performance to subtle niceties for debugging.

Add StringScanner#scan, #check, and #skip overloads for Int (#16557)
Add StringScanner#peek_behind (#16593)
Add convenience methods to StringScanner (#16595)
Improve cursor window format in StringScanner#inspect (#16594)

Thanks @jneen

The memory management model for libxml2 changed in Crystal 1.17 to become manual instead of integrating the GC. The change introduced another memory leak that is now fixed.

Call xmlFree for the string pointer from xmlNodeGetContent (#16688)

Thanks @toddsundsted

Some additional niceties:

Add IO#read_greedy (#16535)
Add FileUtils#rm_f (#12832)
Add Pointer#align_up and #align_down (#16585)
Add HTTP::Server::Response#content_type and #content_length as convenient accessors (#16712)

Thanks @BlobCodes, @CTC97, @zw963

Prefer modern linker (mold or lld) (#16696)

Thanks @straight-shoota

Parse MacroVar with empty expressions: %var{} (#16772)
Parse ProcNotation with empty arg parenthesis: () -> (#16741)
Add --base-path for crystal docs (#16091)

Thanks @straight-shoota, @matiasgarciaisaia

Support for LLVM 22.1 and 23.0 (#16631)

Thanks @HertzDevil

There is a single deprecation in this release, and it is a trivial one: rename Mutex to Sync::Mutex to use the new algorithm introduced in Crystal 1.19.

We’re experimenting with a two-step mechanism to deprecate a feature. First, we soft deprecate the method in the documentation with a DEPRECATE: callout, then after a few releases we’ll hard deprecate by adding the @[Deprecated] annotation.

Soft deprecate Mutex in favor of Sync::Mutex (#16737)

Thanks @ysbaddaden

Thanks

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

Official Linux ARM64 builds

2026-04-07T00:00:00+00:00

This has been a long awaited feature: how to run Crystal on ARM64 CPUs?

Crystal has supported ARM64 as a tier 1 architecture for many years now, and we already distribute an universal build for macOS, but still no ARM64 builds for Linux.

The wait is over! During the development of Crystal 1.19 we bootstrapped a 1.18.2 compiler for ARM64 that was then used to bootstrap official builds for nightlies and the 1.19 release.

The builds are available everywhere we provide an AMD64 build of the compiler for Linux: nightly builds, release tarballs, Docker images, Snap, as well as the install-crystal GitHub action — just select an ubuntu arm runner.

Crystal talk at FOSDEM 2026

2026-01-23T00:00:00+00:00

I’m giving a talk about Crystal at FOSDEM 2026 in Brussels: Crystal: A language for humans and computers. It’s in the Declarative and Minimalistic Computing track, on Sunday, 1 February 2026 at 09:00 in room UB4.136.

The talk is going to be an introduction into some concepts of Crystals. If you are already familiar with the language, I hope it will still be worthwhile.

If a couple of people are interested in a Crystal meetup, maybe we can arrange to gather somewhere during FOSDEM. Let me know in the comments. I’ll bring some Crystal merch.

Hope to see you in Brussels!

In case you can’t make it, the talk is being recorded.

UPDATE: The talk recording is now available. Thanks to the video team at FOSDEM!

Crystal 1.19.1 is released!

2026-01-20T00:00:00+00:00

We are announcing a new Crystal release 1.19.1 with two regressions fixed.

See the release notes of 1.19.0 for all the changes introduced in Crystal 1.19.

Pre-built packages are available on GitHub Releases and our official distribution channels. See crystal-lang.org/install for installation instructions.

This release includes 2 changes since 1.19.0 by 1 contributor. We thank all the contributors for all the effort put into improving the language! ❤️

This patch release fixes regressions in timer conversions from absolute to relative time (#16581, #16583) that led sleep(seconds) to immediately trigger instead of waiting on some platforms (Darwin, BSDs, Windows) — both introduced in 1.19.0.

For more details, visit the full changelog.

Thanks

Reach out to crystal@manas.tech if you’d like to become a direct sponsor or find other ways to support Crystal. We thank you in advance!

Contribute

The Crystal Programming Language

Releasing Execution Contexts

The default execution context

What do execution contexts provide?

Can execution contexts communicate?

How are execution contexts different from the ‘preview MT’ model?

What changes?

The CRYSTAL_WORKERS environment variable

Breaking changes

1. Fibers can switch threads (parallel contexts)

2. Schedulers can switch threads on blocking syscalls

3. Execution contexts don’t support the spawn(same_thread: true) argument

How to fix the same_thread breaking change?

Notes

Crystal 1.20.3 is released!

Stats

Changes

Limit max nesting of sequences of mappings in YAML parsers

Prevent excessive expansion of aliases in YAML parsers

Post Mortem: HTTP Request Smuggling Vulnerability

Timeline

Technical Details

Root Cause

Example

Impact

Severity Assessment

Mitigation

Lessons Learned

References

Acknowledgements

Crystal 1.20.2 is released!

Stats

Changes

Randomness in Range#sample

Crystal 1.20.1 is released!

Stats

Changes

Kernel TLS

Randomness in Range#sample

Crystal 1.19.2 is released!

Stats

Changes

Security

Regressions

Crystal 1.20.0 is released!

Stats

Changes

Breaking

Security

Target features

Execution contexts

Process API

io_uring

Kernel TLS

Macros

Standard library

Compiler

Dependencies

Deprecations

Official Linux ARM64 builds

Crystal talk at FOSDEM 2026

Crystal 1.19.1 is released!

Stats

Changes

The `CRYSTAL_WORKERS` environment variable

3. Execution contexts don’t support the `spawn(same_thread: true)` argument

How to fix the `same_thread` breaking change?

Randomness in `Range#sample`

Randomness in `Range#sample`