Railway base images are very minimal so even if noto-fonts-emoji is installed, SVG text rendering via Sharp wont work unless the full stack is present. What fixed it for me was using a custom Dockerfile and installing librsvg, pango, pangocairo, harfbuzz, and noto-color-emoji. Then run fc-cache. Also make sure your SVG allows font fallback, dont lock it to a single font.

Example Dockerfile

RUN apt-get update && apt-get install -y \

librsvg2-bin \

libpango-1.0-0 \

libpangocairo-1.0-0 \

libharfbuzz0b \

fonts-noto-color-emoji \

fontconfig \

&& rm -rf /var/lib/apt/lists/*

RUN fc-cache -f -v

And in the SVG font-family="Arial, Noto Color Emoji, Noto Emoji". After that emoji rendered the same as local

Hey thanks for the answer.
But when I tried installing the packages needed based on your reply the emoji still doesn't show up (not even as boxes) so the behaviour is the same when I have the fonts from noto-fonts-emoji.ttf file with fontconfig.conf.
And when I tried to list the installed fonts with fc-list from ssh it shows the font emoji available as NotoColorEmoji-Regular.ttf: Noto Color Emoji:style=Regular
Also I was using RAILPACK_DEPLOY_APT_PACKAGES to install the packages

Yeah this is unfortunately a Sharp + SVG limitation, not a Railway one. so I dug into this more and it turns out its not really a Railway issue. Even though fonts-noto-color-emoji shows up in fc-list, Sharp renders SVG text through librsvg > pango > cairo, and cairo SVG backend doesnt support color emoji fonts like Noto Color Emoji. When that happens the emoji glyph just gets dropped, so you see spacing but no box or emoji.

RAILPACK_DEPLOY_APT_PACKAGES does install the fonts, but it doesnt change how Sharp handles SVG text, which is why the behavior stays the same. That also why it can look different across environments. If you need emoji to be reliable, the only real options are replace emojis with inline SVG like Twemoji or render the text to a bitmap first and then composite it with Sharp. Using emoji fonts directly inside SVG <text> with Sharp just isnt reliable anywhere unfortunately.

Hey his issue has been resolved. I removed the package installation and used the Sharp.text() workaround I found from this Sharp issue thread . Although it’s slower than how Sharp processes SVG, we can optimize the surrounding logic to make it just as fast.