[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f2qze6ncqcv3tx":3,"$f14sifz4mj065x":12,"blog-posts":21},{"tagline":4,"link_x":5,"link_youtube":6,"link_linkedin":7,"link_github":8,"bio":9,"home_header":10,"home_message":10,"avatar_url":11},"Founder & Engineer • Fintech • Blockchain • AI ","https:\u002F\u002Fx.com\u002Fivanermolaev_","https:\u002F\u002Fwww.youtube.com\u002F@GetAuth","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fiermolaev\u002F","https:\u002F\u002Fgithub.com\u002FNawy","# Ivan Ermolaev\n\n**CTO & Co-Founder at [Meridyan](https:\u002F\u002Fmeridyan.xyz) - Techstars '26**\n\n\u003Cdiv style=\"display: flex; flex-wrap: wrap-reverse; gap: 16px; align-items: flex-start;\">\n  \u003Cdiv style=\"flex: 1 1 300px; min-width: min(100%, 280px);\">\n    I build things. For most of my life that's meant software - complex, high-stakes systems in fintech, telecom, and aviation. Today it means building bank and blockchain infrastructure from scratch, as a founder.\n  \u003C\u002Fdiv>\n\n  \u003Cimg src=\"https:\u002F\u002Fmedia.ivanermolaev.com\u002FKnMPYJj-0LYK.avif\" alt=\"Ivan Ermolaev\" style=\"flex: 0 0 300px; width: 300px; max-width: 100%; height: auto;\">\n\u003C\u002Fdiv>\n\n*A small, honest aside: I've loved Lovecraft for as long as I can remember. Cosmic horror and distributed systems agree on one thing - the more you learn, the more you realize how much is happening just past what you can see.*\n\n\u003Cimg src=\"https:\u002F\u002Fmedia.ivanermolaev.com\u002FsRWDUYh9Thiu.avif\" alt=\"Ivan Ermolaev\" style=\"width:400px;\"\u002F>\n\n## Now\n\nI'm the CTO and co-founder of [Meridyan](https:\u002F\u002Fmeridyan.xyz), where we're building bank and blockchain infrastructure for people around the world who don't fit neatly inside a traditional bank. We're currently going through Techstars for it. Before this, I spent more than a decade building complex, mission-critical systems in fintech, telecom, and aviation. This is the first thing I've built that's fully mine - and I'm genuinely curious what's next.\n\n## Career\n\n### Scientific Computing - Sheep Genetics, 2014–2015\n\nMy first real job put me in a room with a scientist studying sheep breeding, sitting on an ocean of DNA sequences, field trials, and lab results - all locked inside Oracle. Oracle capped queries at 64kb and ran them in a tightly bounded memory space, which made the kind of massive, cross-referenced selective query the science actually needed nearly impossible. So I built a SQL engine on top of Oracle to remove those limits - parsing with ANTLR, heavy concurrent processing in Java - giving the scientists the full power of SQL without the fence around it. That engine was patented and is still used today, mostly in Australia. Not a bad place to start.\n\n### Sirena Travel, 2015–2016\n\nNext came Sirena Travel and their GDS - the reservation system behind a lot of airline ticketing. I worked on fares and their integration with payment systems, and on the closely related problem of clearing integrations. Java, SOAP, Spring - unglamorous plumbing, but the kind airlines actually run on.\n\n### Megafon \u002F Megalabs, 2016–2017\n\nFrom there I moved to Megalabs, the technology arm of Megafon, one of Russia's largest telecoms. I worked on high-load systems built on Cassandra, serving more than 60 million people across one of the largest countries on earth. These were early days for Docker in production - we ran our services in containers, orchestrated with Docker Swarm, before that was the obvious choice it is now.\n\n### BCS (Broker Credit Service), 2017–2019\n\nAt BCS, a major Russian brokerage, I connected NYSE, NASDAQ, LSE, and other exchanges to brokerage services in Russia, working closely with securities, financial instruments, and Bloomberg systems. We built a distributed stock order processing system in Java from the ground up, on our own Kubernetes infrastructure - our own cloud, isolated and hardened the way a financial exchange needs it to be.\n\n### Ex Machina, Amsterdam, 2019–2020\n\nIn Amsterdam, I joined Ex Machina, building live quiz and voting infrastructure for shows like America's Got Talent, The Voice, and live Twitch broadcasts. This was high load with a strange shape: calm for most of the show, then a spike of millions of requests the instant a host asked the audience to do something - with a hard requirement to respond in under 20 milliseconds, spread across AWS and multiple clouds for resilience. Nothing teaches you about scale like a system that has to survive a studio audience acting all at once.\n\n### ABN AMRO, 2020–2026\n\nAt ABN AMRO, I worked on KYC, payment systems, and cryptography, integrating with Open Banking and building out security architecture across the bank. I worked closely with identity providers - Microsoft Entra ID, Auth0 - and was deeply involved in the cybersecurity design decisions sitting underneath a bank that millions of people trust without ever thinking about it.\n\n## Independent Projects\n\nAlongside the day jobs, I've spent most of my life building things nobody asked me to build.\n\n### Macrofate, 2013–2014\n\nWhile still in college, I built my own game engine from scratch and called it Macrofate. I designed every piece myself - SFML for rendering, Box2D for physics, a custom NoSQL engine to store game data - the full architecture, written entirely in C++. On top of it, I built a game, also called Macrofate: a spaceship survival simulator inspired by FTL.\n\n\n![Macrofate screenshot world generation](https:\u002F\u002Fmedia.ivanermolaev.com\u002FEsISUXeUqRaT.avif)\n![Macrofate screenshot](https:\u002F\u002Fmedia.ivanermolaev.com\u002FyNRQAUkBxbEw.avif)\n\nFind it on [itch.io](https:\u002F\u002Fermolaev.itch.io\u002Fmacrofate) and [IndieDB](https:\u002F\u002Fwww.indiedb.com\u002Fgames\u002Fmacrofate) .\n\n### Finding My People, 2014–2015\n\nThat same drive pushed me further. A friend and I were working on a game, and I realized we needed people we didn't know yet - audio producers, other programmers, talent scattered across the world. At 16, I started searching Facebook for professionals abroad and put together my first international team, to build a horror game together.\n\nFind the game's page on [IndieDB](https:\u002F\u002Fwww.indiedb.com\u002Fgames\u002Fplush-terror).\n\n### Skeletal Animation Engine\n\nAround the same time, I went deep into animation systems and built my own skeletal animation engine - again in C++, with Qt for the interface.\n\n[Read the full story (In Russian)](https:\u002F\u002Fhabr.com\u002Fru\u002Farticles\u002F219509\u002F)\n\n### Mental Shift, 2020–2022\n\nYears later, I chased a different kind of project: an online game called Mental Shift, built with ten people across design, programming, and music - all volunteers, all in the evenings, for the love of it. I found the team and built the way we worked together: dailies, Jira boards, epics, sprint demos we played together online at the end of each cycle. I brought in a consultant who had worked on AAA titles for Sony and Xbox.\n\n![Mental Shift screenshot 1](https:\u002F\u002Fmedia.ivanermolaev.com\u002FE6TthGGAwhQ0.avif)\n![Mental Shift screenshot 2](https:\u002F\u002Fmedia.ivanermolaev.com\u002FSX2pM_Kstg5W.avif)\n\n\nThe post-COVID funding climate of 2021 made it impossible to close a deal with a publisher to bring the game to market - but everything I learned building and running that team stayed with me.\n\n### Versolid, 2022–2024\n\nGame studios don't use Git - they use Subversion or Perforce, and Perforce gave our team constant trouble. So I built our own version control system in C#: fast, indexed, handling binary file locks, syncing efficiently across a small team. We called the workflow model \"light branch\" - a bounded work area, scoped by folders, where one developer's changes stay isolated until ready. I later rewrote the whole thing in Rust, and with a team of five we built a full MVP - server, client, and a UI for designers.\n\n![Versolid History](https:\u002F\u002Fmedia.ivanermolaev.com\u002FAmPhOaeDpD9E.avif)\n\nWe called it Versolid - version, done solidly. Programmers and artists who tried it loved it, and we piloted it with a few indie teams. But indie studios run on thin margins, and when I pitched it to engineers at Ubisoft, Guerrilla Games, Funcom, and Bohemia Interactive, I learned something more useful than a sale: even when people love a technology, large studios are bound tightly to their existing infrastructure, and internal incentives often work against adopting something new, no matter how good it is. That's when I read *The Innovator's Dilemma* and *The Innovator's Solution*, and later *Crossing the Chasm* - and started to understand why.\n\n## What I Took From It\n\nVersolid taught me I had the engineering and architectural skills to build almost anything - but not yet the skills to build a business around it. So I went back to school on that, properly: Alex Osterwalder's *Business Model Generation*, *Value Proposition Design*, and *Testing Business Models*, and Steve Blank's *The Startup Owner's Manual*. That reading, and the scars from Versolid, are a big part of what got me into Techstars.\n\n## Follow Along\n\nThanks for reading this far. If you want to keep up with what I'm building, find me on [YouTube](https:\u002F\u002Fwww.youtube.com\u002F@GetAuth)  or [LinkedIn](https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fiermolaev\u002F).\n","","https:\u002F\u002Fmedia.ivanermolaev.com\u002FKnMPYJj-0LYK.avif",[13,17],{"id":14,"name":15,"slug":15,"colorHex":16},3,"infra","#29a38b",{"id":18,"name":19,"slug":19,"colorHex":20},6,"security","#5aa329",[22,32],{"id":23,"nanoid":24,"title":25,"content":26,"excerpt":27,"createdAt":28,"updatedAt":29,"tags":30},"019ffbf0-a08e-7679-850a-e7080962807a","zeDwEi88Au","How to Make Linux Files Undeletable Even for Root Users","# How to Make Linux Files Immutable (Even Root Can't Touch Them!)\n\nMost Linux users believe that the **root** user is all-powerful. Root can read any file, write to any file, and delete any file. But what if you could create a file that even root cannot modify or delete?\n\nThis isn't a myth. Linux has a built-in feature that lets you lock a file so tightly that not even superuser privileges can break it. In this article, you will learn how to use the `chattr` command to make files **immutable**, why this is incredibly useful for security, and how to apply it to protect critical system files.\n\n## Prerequisites\n\nBefore you start, make sure you have:\n\n- Access to a Linux terminal.\n- **Root or sudo privileges** (you need these to set the lock, ironically).\n- Basic familiarity with Linux file permissions.\n\n## What is `chattr`?\n\n`chattr` stands for **change attribute**. Unlike `chmod` (which changes *permissions* like read, write, and execute), `chattr` changes special *file system attributes* that control how the file behaves at a much deeper level.\n\nThese attributes are enforced by the file system itself (like ext4), not just by the standard Unix permission model. This is why they can override even root's authority.\n\n## The Immutable Attribute: `+i`\n\nThe most powerful attribute available is `i`, which stands for **immutable**.\n\nWhen a file has the immutable attribute set:\n\n- It **cannot be modified** (no writing).\n- It **cannot be deleted**.\n- It **cannot be renamed**.\n- No new **links** can be created to it.\n- Its metadata (like timestamps) **cannot be changed**.\n\nHere is the official definition from the Linux man pages:\n\n> \"A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file, most of the file's metadata can not be modified, and the file can not be opened in write mode. Only the superuser or a process possessing the `CAP_LINUX_IMMUTABLE` capability can set or clear this attribute.\"\n\n### How to Lock a File\n\nTo make a file immutable, use the `+i` flag with `chattr`:\n\n```shell\n# Lock the file\nsudo chattr +i \u002Fpath\u002Fto\u002Fyour\u002Ffile.txt\n```\n\nOnce this command runs, try to edit or delete the file. You will get a **\"Permission denied\"** error, even if you are logged in as root.\n\n### How to Check the Status\n\nYou can verify if a file is locked using the `lsattr` (list attributes) command:\n\n```shell\nlsattr \u002Fpath\u002Fto\u002Fyour\u002Ffile.txt\n```\n\nIf the file is immutable, you will see an `i` in the output, like this:\n`----i---------e--- \u002Fpath\u002Fto\u002Fyour\u002Ffile.txt`\n\n### How to Unlock a File\n\nIf you need to edit the file later, you must remove the attribute using `-i`:\n\n```shell\n# Unlock the file\nsudo chattr -i \u002Fpath\u002Fto\u002Fyour\u002Ffile.txt\n```\n\nOnce unlocked, the file returns to normal, and you can edit or delete it as usual.\n\n## Why Should You Use This? Protecting Against Rootkits\n\nYou might be wondering: \"If I trust myself as root, why do I need to lock myself out?\"\n\nThe answer is **security against attackers**, specifically **rootkits** and malware. If a hacker gains root access to your server, one of the first things they often do is:\n\n1.  Create a new hidden user (a backdoor).\n2.  Change a password to gain access to an existing account.\n\nThey do this by editing two critical files:\n- `\u002Fetc\u002Fpasswd` (Stores user login information).\n- `\u002Fetc\u002Fshadow` (Stores encrypted password hashes).\n\nIf you make these files immutable, even a rootkit with root privileges **cannot add new users or change passwords** through standard file editing methods. This can stop certain attacks in their tracks.\n\n### Practical Example: Locking `passwd` and `shadow`\n\nHere is how you would apply this security measure to protect your login credentials:\n\n```shell\n# Lock the user database file\nsudo chattr +i \u002Fetc\u002Fpasswd\n\n# Lock the password hash file\nsudo chattr +i \u002Fetc\u002Fshadow\n```\n\nNow, if malware tries to run a command like `useradd` to create a new hacker account, the system will throw an error because it cannot write to these files.\n\n**Important:** If you legitimately need to add a new user or change a password, you must remember to unlock these files first, or the standard `useradd`\u002F`passwd` commands will fail!\n\n```shell\n# Remember to unlock before making legitimate changes!\nsudo chattr -i \u002Fetc\u002Fpasswd\nsudo chattr -i \u002Fetc\u002Fshadow\n\n# Now you can add users normally\nsudo useradd newuser\n\n# Lock it again immediately after!\nsudo chattr +i \u002Fetc\u002Fpasswd\nsudo chattr +i \u002Fetc\u002Fshadow\n```\n\n## A Word of Caution\n\nWhile `chattr +i` is powerful, it is not a magic bullet:\n\n- **It relies on the filesystem:** This feature works on `ext2\u002F3\u002F4`, `btrfs`, and `XFS`, but might behave differently or not be supported on other filesystems.\n- **Physical access bypasses it:** If an attacker boots your server using a live USB\u002FCD, they can mount your hard drive using a *different* operating system kernel, which might ignore the immutable flag, or they could use tools to alter it directly.\n- **It can break automation:** If you have scripts that update `\u002Fetc\u002Fpasswd` (like automated user provisioning), the immutable flag will cause those scripts to fail. Always test in a safe environment first.\n\n## Conclusion\n\nThe `chattr` command with the `+i` flag is a hidden gem in Linux system administration. It provides a layer of defense that goes beyond standard user permissions, protecting critical files from accidental changes and malicious rootkits alike.\n\n**Next Steps:** Try setting the immutable flag on a test file first to see how the \"Permission Denied\" error looks. Once you are comfortable, consider auditing your `\u002Fetc\u002Fpasswd` and `\u002Fetc\u002Fshadow` files and locking them down for an extra layer of security on your production servers.","Use chattr +i to make Linux files immutable, preventing deletion, modification, or renaming even by root users. Ideal for protecting critical system files like \u002Fetc\u002Fpasswd and \u002Fetc\u002Fshadow from rootkit attacks and unauthorized changes.","2026-08-13T16:24:38.000Z","2026-08-13T16:26:57.000Z",[31],{"id":18,"name":19,"slug":19,"colorHex":20},{"id":33,"nanoid":34,"title":35,"content":36,"excerpt":37,"createdAt":38,"updatedAt":39,"tags":40},"019ff6e5-2e8e-76f1-93b3-90ba6da111cc","cBix_kVnzs","How I Deployed My Full-Stack App on Cloudflare's Edge Network","# Deploying a Full-Stack App with Cloudflare Workers, Pages, and D1\n![cloudflare logo](https:\u002F\u002Fmedia.ivanermolaev.com\u002FA9sU7Y1EzWEf.avif)\n\n\nFinding the right place to host a modern web app can be tricky. You want something fast, affordable, and easy to manage, without juggling five different services for your frontend, backend, database, and cache.\n\nThat's exactly what I found when I looked into deploying my blog using **Cloudflare Workers** paired with a **D1 SQLite database**. The setup process took a bit of learning, but the result was a fast, globally distributed app that \"just works.\" In this article, I'll walk you through what Cloudflare Workers and Pages are, how the **Wrangler CLI** ties everything together, and the exact steps to get your project live.\n\n## Prerequisites\n\nBefore you start, make sure you have:\n\n- A **Cloudflare account** (the free tier is enough to get started).\n- **Node.js** and **npm** installed on your machine.\n- A frontend project built with a framework that supports Cloudflare deployment, such as **SvelteKit** or **Nuxt**. Both of these frameworks have official adapters that optimize your app to run on Cloudflare's infrastructure.\n\n## What Are Cloudflare Workers and Pages?\n\n**Cloudflare Workers** let you run your backend code (like API routes or server-side rendering) on Cloudflare's global network, instead of a single server in one location. This means your code runs physically closer to your users, which makes your app feel faster.\n\n**Cloudflare Pages** is Cloudflare's platform for hosting static assets (HTML, CSS, JavaScript, images). When combined with Workers, you get a complete setup: static files served instantly from the edge, and dynamic logic handled by Workers.\n\nIf you're using a popular framework like **SvelteKit** or **Nuxt**, you don't have to build this integration yourself. These frameworks include built-in support (via adapters or presets) that automatically package your app to run smoothly on Workers and Pages.\n\n## Wrangler: Your Command-Line Companion\n\n**Wrangler** is the official CLI tool for the Cloudflare Developer Platform. Think of it as your remote control for everything Cloudflare: deploying code, managing databases, setting secrets, and more, all from your terminal.\n\n### The Configuration File\n\nWrangler reads its settings from a file named `wrangler.jsonc`, located in your project's root folder. Here's what a typical configuration looks like:\n\n```json\n{\n  \"$schema\": \"node_modules\u002Fwrangler\u002Fconfig-schema.json\",\n  \"name\": \"\u003Cworker-name>\",\n  \"compatibility_date\": \"2025-07-15\",\n  \"compatibility_flags\": [\"nodejs_compat\"],\n  \"main\": \".\u002F.output\u002Fserver\u002Findex.mjs\",\n  \"assets\": { \"directory\": \".\u002F.output\u002Fpublic\" },\n  \"d1_databases\": [\n    {\n      \"binding\": \"DB\",\n      \"database_name\": \"\u003Cname>\",\n      \"database_id\": \"\u003Cid>\",\n      \"migrations_dir\": \"server\u002Fdatabase\u002Fmigrations\"\n    }\n  ],\n  \"kv_namespaces\": [\n    {\n      \"binding\": \"KV\",\n      \"id\": \"\u003Cid>\",\n      \"remote\": true\n    }\n  ]\n}\n```\n\nLet's break down the key fields:\n\n- **`name`**: The identifier for your Worker on Cloudflare.\n- **`main`**: The entry point to your compiled server code.\n- **`assets`**: The folder containing your static frontend files.\n- **`d1_databases`**: Connects your Worker to a **D1** database (Cloudflare's serverless SQLite offering).\n- **`kv_namespaces`**: Connects your Worker to a **KV** namespace, a simple key-value store often used for caching.\n\n## Step-by-Step Deployment Guide\n\nHere is the complete workflow, from logging in to going live.\n\n```mermaid\nflowchart TD\n    A[Login to Cloudflare] --> B[Create D1 Database]\n    B --> C[Create KV Namespace]\n    C --> D[Set Secrets]\n    D --> E[Deploy with Wrangler]\n    E --> F[App Live on Cloudflare Edge]\n```\n\n### 1. Log In to Cloudflare\n\nFirst, authenticate your terminal with your Cloudflare account. This opens a browser window for you to approve access.\n\n```shell\nnpx wrangler login\n```\n\n### 2. Create a D1 Database\n\nD1 is Cloudflare's serverless SQL database, built on SQLite. Create one with a simple command:\n\n```shell\nnpx wrangler d1 create \u003Cdatabase-name>\n```\n\nThis command returns a **database ID**. Copy this value into the `database_id` field in your `wrangler.jsonc` file.\n\n### 3. Create a KV Namespace\n\nIf your app needs caching (for example, storing session data or frequently accessed content), create a **Key-Value namespace**:\n\n```shell\nnpx wrangler kv namespace create \u003Ckv-name>\n```\n\nJust like with D1, you'll get an ID to add to your configuration file.\n\n### 4. Set Your Secrets\n\nNever hard-code sensitive values like API keys or database passwords into your code. Instead, use Wrangler's secret management:\n\n```shell\nnpx wrangler secret put \u003CNAME>\n```\n\nDon't worry about your secrets showing up in your shell history. Wrangler provides a **masked input prompt**, so the value never gets typed or logged in plain text.\n\n### 5. Deploy\n\nOnce everything is configured, deploying is a single command:\n\n```shell\nnpx wrangler deploy\n```\n\nWrangler will bundle your app, upload it to Cloudflare's network, and make it live within seconds.\n\n## Practical Tip: Local Development\n\nBefore deploying, you can test your Worker locally using:\n\n```shell\nnpx wrangler dev\n```\n\nThis spins up a local environment that closely mimics production, including access to your D1 database and KV namespace, so you can catch issues early.\n\n## Final Thoughts\n\nMy overall experience with Cloudflare Workers and Pages was **very positive**. Yes, setting up the configuration takes a bit of time, and adjusting your framework to fit Cloudflare's model requires some learning. But once everything clicks into place, you get a fast, reliable, and cost-effective way to host a full-stack application.\n\n**Next step:** If you're using SvelteKit or Nuxt, check out their official Cloudflare deployment guides to see the specific adapter setup for your framework. Then try deploying a small test project using the steps above; it's the best way to get comfortable with the workflow before moving your main app over.","Deploy full-stack apps globally with Cloudflare Workers, Pages, and D1. Host your backend, frontend, and database seamlessly on Cloudflare's edge network using Wrangler CLI.","2026-08-12T16:54:02.000Z","2026-08-13T14:00:19.000Z",[41],{"id":14,"name":15,"slug":15,"colorHex":16}]