DEV Community: Kondo Uchio

RubyKaigi Teaser: Ruby on the Edge

Kondo Uchio — Mon, 23 Mar 2026 14:29:24 +0000

Are you interested in lightweight web development on the edge? Platforms like Cloudflare Workers and Fastly Compute have been gaining tremendous popularity.

However, edge development in Ruby still faces significant challenges. One of the biggest issues, I believe, is file size. ruby.wasm is an incredible piece of work, but since it packs a fully-featured Ruby into Wasm, the generated artifact is simply too large for edge use cases.
Do you really need that much overhead just to do "a little something"?

My new framework, Uzumibi (a Japanese name, like "Hono" — it means live embers buried under ash), breaks through that wall.

Here's a very basic example of Uzumibi code:

class App < Uzumibi::Router
  get "/" do |req, res|
    res.status_code = 200
    res.headers = {
      "content-type" => "text/plain",
      "x-powered-by" => "#{RUBY_ENGINE} #{RUBY_VERSION}"
    }
    res.body = "It works!\n"
    res
  end
end

$APP = App.new

The Evolution of mruby/edge

Let me give you a bit of background. At RubyKaigi 2024, I gave a talk about mruby/edge, a lightweight, Wasm-friendly implementation of mruby written in Rust.

An mruby for WebAssembly - RubyKaigi 2024

RubyKaigi 2024, #rubykaigi

rubykaigi.org

udzura.jp

At the time, it was barely more than an implementation that could run a Fibonacci function — calling it a PoC would have been generous. The idea of running a Wasm file based on mruby/edge on the edge felt like a pipe dream.

Two years later, mruby/edge has evolved dramatically. It now covers over 80% of the instructions implemented by the mruby 3.4 VM. We prioritized the most critical instructions and got them working. We've also completed standard library implementations, using mruby/c 3.x as a benchmark, focusing on the most "Ruby-like" features. Documentation is available in COVERAGE.md on the mruby/edge repository.

And of course, it still runs easily in the browser, so we've already prepared a Playground for you. Please give it a try!

mruby/edge Playground

mrubyedge.github.io

(The Playground uses mruby-compiler2, created by my dear and respected friend hasumikin. mruby/edge doesn't have its own compiler yet.)

The time has finally come. I've released Uzumibi, a framework built on mruby/edge, and I'm actively developing it.

The Firepower of Uzumibi

Here are the key features of Uzumibi:

Lightweight artifacts. A Cloudflare Workers app with realistic functionality weighs in at around 1.2 MiB, and compresses to under 400 KiB. That's well within the free tier limits, and loads fast.
An intuitive, Sinatra-like routing DSL that feels natural for Ruby developers.
Multiple project templates. Currently supported: Cloudflare Workers, Fastly Compute, Fermyon Cloud (Spin), and as a bonus, Google Cloud Run(!). Let me know what other platforms you'd like to see supported.
You can develop APIs entirely in the browser. This is powered by Web (Service) Workers.

Note: Complex features like external service integrations currently only work on Cloudflare Workers. Sorry about that!

With Uzumibi, you can deploy an application to the edge just by writing Ruby code (okay, you might need a little bit of configuration and some dashboard clicks). Uzumibi is a framework for stubborn Ruby developers (like me!) who find JavaScript and TypeScript just a little bit... not quite right.

Uzumibi is brand new — there will be missing features and bugs. But that also means the possibilities are wide open. Come to RubyKaigi and hear about the potential of this newborn "new Ruby."

See You in Hakodate!

My talk is scheduled at RubyKaigi 2026 in Hakodate, Hokkaido. Check the official schedule for the exact date and time:

Schedule - RubyKaigi 2026

RubyKaigi 2026, #rubykaigi

rubykaigi.org

I'm going to have a talk on April 23, the 2nd day of RubyKaigi!

Can't wait? Great news for those who want to try it right away — I've published "Beginning Uzumibi" online. Give it a spin, and then come tell me your thoughts in person at Hakodate!

(Online issues and pull requests are, of course, also very welcome!)

Trying seccomp via mruby

Kondo Uchio — Thu, 16 Nov 2017 05:30:51 +0000

seccomp?

seccomp(2) is a Linux system call that filters processes' syscall invocations. After Linux 3.5, they introduced "seccomp mode 2" that allow systems to filter syscalls by syscall numbers and their arguments.

This is also one of basic containers features, e.g. Docker uses this.

It uses BPF (Berkeley Packet Filter), which is also used in libpcap, to filter syscalls as fast as possible.

mruby?

mruby is one of the Ruby implementations (FYI mruby is created by Matz, as MRI is founded by Matz). It is designed to be embeddable into gadgets and to be lightweight than CRuby.

As a side effect of embedding features, mruby has very clean and concise C API, so it is easy to write C bindings/systems programmings with it. It is similar to Lua language in many aspects.

I am going to try to use seccomp basic features via libseccomp, writing mruby's gem(mrbgem) to bind libseccomp.

Here is mruby-seccomp. You can build a mruby binary with seccomp access, by checking out this repo in some Linux and just hit make(building mruby itself requires CRuby, bison and some libraries).

Basic usage

In C level, you can create seccomp context by seccomp_init(3), add filter rules by seccomp_rule_add(3), then load to current process by seccomp_load(3).

A seccomp context has a default action:
:kill => SCMP_ACT_KILL, :allow => SCMP_ACT_ALLOW, :trap => SCMP_ACT_TRAP, ...
Then you can add custom filter actions with syscall and arguments specifications.

Use :kill by default to make a whitelist, and use :allow a blacklist.

This is a blacklist that restricts uname(2) calls. Build with mruby-uname.

context = Seccomp.new(default: :allow) do |rule|
  rule.trap(:uname)
end

context.load
Uname.nodename # Really calls `uname(2)` !

$ ./mruby/bin/mruby /tmp/test.rb 
Bad system call

Bad system call implies SIGSYS - you even can trap this.

Combination with `fork()/exec()`

Loaded seccomp's information will not be changed after fork/clone and execve, as a kernel document says.

You can load a seccomp context just after fork() and then do execve(), to create a "sandbox" container - which restricts child processes to call specified syscalls.

# fork from https://github.com/iij/mruby-process
# exec from https://github.com/haconiwa/mruby-exec
context = Seccomp.new(default: :allow) do |rule|
  rule.kill(:mkdir, Seccomp::ARG(:>=, 0), Seccomp::ARG(:>=, 0))
end

pid = Process.fork do
  context.load

  puts "==== It will be jailed. Please try to mkdir"
  exec "/bin/sh"
end

p(Process.waitpid2 pid)

$ ./mruby/bin/mruby /tmp/jail.rb 
==== It will be jailed. Please try to mkdir
sh-4.2$ mkdir /tmp/test1234
Bad system call

This is similar to Linux Capabilities, but seccomp has a finer granularity to control programs.

Advanced features

Using seccomp we can catch SIGSYS with the informations of what syscall is blocked(via struct siginfo_t). mruby-seccomp supports this.

context = Seccomp.new(default: :allow) do |rule|
  rule.trap(:uname)
end
Seccomp.on_trap do |syscall|
  puts "Trapped: syscall #{Seccomp.syscall_to_name(syscall)} = ##{syscall}"
end
context.load

begin
  # Then hit `uname(2)`
  p "nodename: " + Uname.nodename
rescue => e
  puts "Catch as error: " + e.message
  puts "Trapping is OK"
end

$ ./mruby/bin/mruby /tmp/trap.rb 
Trapped: syscall uname = #63
Catch as error: uname failed
Trapping is OK

NOTE: Signal handlers will be cleaned after exec(). So exec()'ing to be bash and trapping uname(1) hit is unsupported now.

Conclusion

seccomp can restrict a process and a process tree's syscall invocations. We can do an experiment using mruby, mruby-seccomp and some mrbgems about processes control.

BTW seccomp is supported in Docker, LXC and Haconiwa.

Pull requests to mruby-seccomp is welcomed!

Original Japanese article

Original article written by me in Japanese:

http://udzura.hatenablog.jp/entry/2016/11/18/160020

Writing a small bare-metal container

Kondo Uchio — Wed, 15 Nov 2017 05:16:26 +0000

First, run debootstrap command.

$ sudo mkdir /root/devto
$ sudo debootstrap --variant=minbase \
    jessie \
    /root/devto \
    http://ftp.jp.debian.org/debian

Then, prepare a small ruby script:

# $ cat after-unshare.rb 
#!/usr/bin/env ruby
container_name = ARGV[0]
raise unless container_name
Dir.mkdir "/sys/fs/cgroup/cpu/#{container_name}" rescue puts("skip")
File.write "/sys/fs/cgroup/cpu/#{container_name}/cpu.cfs_period_us", "100000"
File.write "/sys/fs/cgroup/cpu/#{container_name}/cpu.cfs_quota_us",   "30000" # 30%
File.write "/sys/fs/cgroup/cpu/#{container_name}/tasks", $$.to_s
Dir.chroot "/root/#{container_name}"
Dir.chdir "/"
system "mount --make-rprivate /"
system "mount -t proc proc /proc"
system "hostname #{container_name}.example.com"

exec "bash -l"

After all, run this ruby script via unshare(1) with options below:

$ chmod a+x after-unshare.rb
$ sudo unshare \
    --fork \
    --pid \
    --mount \
    --uts \
    `pwd`/after-unshare.rb devto

That's it!! You're got into the container!!

root@devto:/# ps auxf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.3  0.3  20288  3240 ?        S    05:13   0:00 bash -l
root         7  0.0  0.2  17496  2080 ?        R+   05:13   0:00 ps auxf