Coder Legion - Recent posts tagged make

Make for Small Business: What It Is, What It Costs, and When to Use It

Fri, 23 Oct 2026 15:50:00 +0000

If you have compared automation tools for more than five minutes, you have met Make. It used to be called Integromat, and it is best known for one thing: a visual builder that looks like a real diagram, with little circles connected by lines that show your data moving from one app to the next. For a lot of people, that picture is the moment automation finally clicks.

This guide is the honest version. What Make is, what it does better than almost anyone, what it costs, and where it starts to pinch for a growing small business.

What Make actually is

Make is a workflow automation tool, in the same family as Zapier and n8n. You build a scenario: a trigger that starts it, then modules (the steps) that do the work, all laid out on a visual canvas. Read a row, send an email, call an API, filter the junk. It is the same trigger-steps-workflow model I broke down in what is n8n, just with Make's own names on it.

What Make is genuinely great at

Make is particularly useful when a workflow needs visible branching and data transformation:

Visual flow control. Routers split one input down several paths, iterators loop over a list, and aggregators bundle the results back together on the canvas.
Built-in error handling. This is the underrated one. You can attach error handlers to a module and choose what happens when a step fails: retry, skip, roll back, or stop cleanly. A failed run does not silently lose your data, which matters the moment a real business process depends on it.
Data stores. Make has a small built-in database, so a scenario can remember things between runs: a list of processed orders, a counter, a lookup table. That kind of memory usually means bolting on a spreadsheet elsewhere.
A broad integration catalog plus a generic HTTP module for services with an accessible API. Compare the actual module count and monthly volume before assuming it will be cheaper than Zapier.

What Make costs

Make bills with credits, the term that replaced operations. For non-AI apps, one operation is generally one credit, and most modules use one credit each time they perform an operation. On August 1, 2026, the public pricing page listed Free with 1,000 credits and Core from $12/month for 10,000 credits when billed annually. Prices and AI credit rules may change.

The thing to watch is how credits add up. A scenario with several modules spends a credit per module, per run. At low volume this is comfortable and cheap. As volume climbs, or as scenarios get longer, the credit count grows with every step you add. It is predictable, but it does scale with complexity. I put real numbers next to Zapier and n8n in Zapier vs Make vs n8n pricing.

Where Make can pinch

A few honest caveats. First, the learning curve is a little steeper than Zapier. The same power that makes the canvas great also means there is more to understand before your first scenario runs. Second, because credits are spent per module per run, a heavy, many-step automation running thousands of times a month can get more expensive than you expected, and you cannot host it yourself to escape the meter.

Third, watch your scheduled triggers. A scenario that polls for new data runs on a timer whether or not anything is waiting, so one set to check every 15 minutes wakes up around 2,880 times a month. Exactly how those empty checks are billed has shifted as Make moved from operations to credits, so confirm the current rules for your plan in Make's docs. Either way the safe habit is the same: use instant (webhook) triggers where the app supports them, and do not poll more often than you actually need.

None of these is a dealbreaker. They are just the trade-offs to know before you commit a core business process to it.

What you can automate with Make

Theory is dull, so here is what Make actually does for a small team. Each of these is a real scenario you can build:

Catch and follow up on new leads before they go cold, pulling them from forms, email, and chat into one place. See small business automation in the Philippines.
Route one input down several paths at once, which is where Make's visual canvas earns its keep: send a new order to your CRM, your accounting sheet, and a Slack channel in a single scenario.
Turn a free Google Form into a real intake pipeline, so submissions are logged, tagged, and acted on automatically. See the free Google Forms automation, no Zapier needed.
Replace manual copy-paste between the tools you already pay for, so nobody moves data by hand all day.

None of these need a developer on staff. They need a clear process and a tool that can run it. Before you commit, it is worth knowing what the same workflow would cost on each platform, which I broke down in how much it costs to automate lead follow-up.

Is Make right for your business?

For a lot of small businesses, yes. Make is an excellent fit when your automations have real branching logic, when you want to actually see the workflow as a diagram, and when you are price-sensitive on multi-step scenarios where Zapier would charge more. If you like the visual approach and your volume is moderate, Make is a genuinely good home.

It is the wrong fit when self-hosting is a requirement or when repeated modules make the credit budget unattractive. In those cases, compare n8n, which offers a self-hosted option and bills Cloud by complete workflow executions. If the workflow is only Forms to Sheets or another connection the vendor already provides, use that native route first. The pricing comparison shows how to calculate the same workflow under each billing model.

Where to learn Make

Make has the best learning resource of the three big tools, and it is their own: Make Academy. It is free, self-paced, runs from Foundation to Advanced, and you earn real Credly badges you can put on LinkedIn. Plan on roughly 15 hours for the full path. If you only do one tool's training properly, make it this one, and build the examples in your own account as you go rather than just watching. That is the difference between having seen it and being able to do it.

Where to start

Pick the most annoying repetitive task in your week and describe it in one sentence: when X happens, do Y, then tell me. Build that single scenario on the free plan and let it run for a week. Keep the first one small; a scenario that reliably saves ten minutes a day teaches you more than an ambitious one that breaks on its first edge case. Once it is running, the next handful of tasks become obvious. If you would rather have the first few built properly, with error handling so they do not fail silently, that is what I do.

Sources

Not sure which tool fits?

Tell me the most repetitive task in your week. I can map a simple workflow for it and tell you honestly whether to build it on Make, Zapier, or n8n, and what it will cost to run.

Get the map

Originally published on FloxoLab.

Determinism Is a Core Contract in Build Caching

Tue, 04 Aug 2026 14:30:00 +0000

If you have set up a remote build cache and watched the hit rate sit stubbornly low, nondeterministic outputs are one important suspect — but not the only one. Source churn, changing flags, platform differences, toolchain changes, eviction, and incomplete input declarations also cause misses. Nondeterminism is particularly dangerous because it can quietly reduce reuse or make cached results untrustworthy without producing an obvious build error. It is worth understanding exactly how that happens and how to isolate it.

Why determinism is the contract, not a nice-to-have

A build cache works by fingerprinting an action's inputs and using that fingerprint to look up a previously computed output. The entire scheme rests on one assumption: identical inputs produce identical outputs. That is the contract. Break it and one of two bad things happens.

If the cache keys only on inputs — which is how these systems work — and your action is nondeterministic, then the cache will happily hand back an output for those inputs, but not necessarily the one a fresh run would produce. Best case, the variation is cosmetic and harmless. Worst case, you have just served a subtly wrong artifact from cache and you will spend a very confusing afternoon. Either way, the cache is now a source of doubt rather than speed.

Another operational outcome is cascading misses, and that is where determinism stops being abstract.

One bad action poisons everything downstream

Builds are graphs. The output of one action is the input to the next. So consider what happens when a single early action — say, a code generator — embeds the current timestamp in its output. Each time that generator actually runs, the file it produces is byte-for-byte different, so its content hash changes.

Whenever that generator has to execute again — because its entry was evicted, the cache was bypassed, or another declared input changed — it produces a new content digest. Every action that consumes the generated file then sees a different input and misses its previous cache entry. Their outputs feed further actions, so the effect can cascade through the subgraph. You did not merely lose reuse for one action; you invalidated downstream keys even when the semantic content did not need to change.

Where nondeterminism actually comes from

The sources are mundane, which is what makes them easy to miss. The usual suspects:

Timestamps baked into outputs — __DATE__ and __TIME__ macros, build IDs, and the modification times stored inside archive formats like .a, .tar, and .zip.
Absolute paths leaking into outputs — debug info that records the full build directory, __FILE__ expansions, paths embedded by the linker. Build the same code in /home/alice and /home/bob and you get different bytes.
Iteration order — generating code by walking a hash map or set, whose iteration order is unspecified, so the output lines come out shuffled run to run.
Concurrency — actions that assemble output from parallel work without imposing a stable order on the result.
Randomness — UUIDs, unseeded PRNGs, anything that reaches for entropy at build time.
The ambient environment — locale, hostname, username, and stray environment variables that the action reads but never declared as inputs.
Filesystem ordering — relying on readdir order, which varies across filesystems and runs.

None of these throws an error. Each just makes one action's output wiggle, and the cache does the rest of the damage.

How to hunt them down

The basic diagnostic is to execute the same build twice from clean, isolated directories with cache reuse disabled, then compare the outputs bit for bit. Anything that differs deserves investigation. diffoscope is the right tool here — it understands archives, binaries, and debug information and can show not just that two outputs differ but where.

The fixes are well-trodden, because the reproducible-builds community has been fighting this war for years:

Timestamps: honor SOURCE_DATE_EPOCH so embedded dates are fixed rather than "now"; build archives in deterministic mode (tar --sort=name --mtime=..., ar in its deterministic D mode).
Absolute paths: use -ffile-prefix-map / -fdebug-prefix-map to rewrite build paths to a stable placeholder, so debug info does not depend on where you built.
Iteration order: sort before you emit. If codegen walks a map, sort the keys first. Never let an unordered container decide output order.
Environment: pin the locale (LC_ALL=C), and run actions in a sandbox that only exposes declared inputs, so an undeclared environment dependency fails loudly instead of silently varying.
Randomness: seed it, or design it out. A build is not the place for entropy.

Hermeticity is how you keep it fixed

Fixing the determinism bugs you have is half the job. The other half is preventing new ones, and hermetic, sandboxed builds remove many sources of ambient input. A filesystem sandbox can hide undeclared files and tools, and a controlled environment can pin locale and environment variables. Sandboxing alone does not necessarily hide the wall clock, randomness, hostname, kernel details, or every network source; those must be blocked, virtualized, or deliberately normalized. The goal is to make undeclared dependencies fail loudly or become stable rather than silently changing outputs.

Measure it, because it regresses

Determinism is not a one-time cleanup. It rots. Someone adds a code generator, someone embeds a build timestamp "just for diagnostics," and reuse slides without anyone noticing. Treat cache hit rate as a first-class metric, but segment it by action type, platform, branch, and miss reason because determinism is only one contributor. Track reproducibility separately with scheduled rebuild-and-compare tests. When hit rate drops and action keys churn without meaningful input changes, reach for build-twice-and-diff before blaming the cache infrastructure.

That is the real point. Determinism is not purity for its own sake. Along with complete input declarations, compatible platforms and toolchains, and retained cache entries, it is a precondition for trustworthy reuse. Get it wrong and the cache may return questionable outputs or lose reuse across a large subgraph. Get it right and equivalent actions can reliably share results across developers and CI. Determinism is not the whole cache system, but it is part of its correctness contract.

Further reading: the Reproducible Builds documentation

Understanding Systemd.exec - Part 1: How to Secure Applications Running in Systemd?

Sat, 02 May 2026 02:27:26 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on GitHub. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

If you are running applications with systemd and want to restrict how they interact with Linux kernel features (like filesystem, processes, and capabilities), you can use the systemd.exec configuration options.

In this article I will be going to explain how to use these options to secure your application.

What are systemd.exec options?

Systemd.exec options are a set of configuration options that are used to configure how a systemd service interacts with the Linux kernel.

This feature is mainly used to provide security for the applications running in systemd.

Why we need this option in first place?

Hardening services (Postgres, Nginx, workers, etc) which are mostly open to the internet
Reducing blast radius after compromise
Lightweight (no container overhead)

How is this different from Docker?

Works on a single process/service.
Applies restrictions on top of the host.
Uses kernel features (namespaces, cgroups, capabilities)
Shares the same root filesystem (by default)
No packaging, no images

What is the real usecase?

Let's take an example of service.

/etc/systemd/system/myapp.service

Inside this file, we can control:

Where the app runs
Which user it runs as
What it can access
How secure / isolated it is
What resources it can use

Most common options

Run a service as non-root (security)

Set User= Group= to a non-privileged user (e.g. postgres, www-data).
This will prevent the service from running as root, which can lead to security vulnerabilities.

For example:

[Service]
User=postgres
Group=postgres

Restrict filesystem access

Set ProtectSystem= ProtectHome= ReadWritePaths= ReadOnlyPaths= to control filesystem access.
This will make service only read/ write specifed directory.

Example:

[Service]
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Isolate runtime environment (like lightweight container)

Set PrivateTmp=yes NoNewPrivileges=yes to isolate runtime environment.
As there is no container like docker this will be running in the host but under private tmp and no new privileges.

Example:

[Service]
PrivateTmp=yes
NoNewPrivileges=yes

Limit resources (avoid abuse / crashes)

Set CPUQuota= MemoryMax= MemoryHigh= MemoryLimit= MemoryAccounting= to limit resources.
If we want specific service to use only limited resources, we can use these options.

Example:

[Service]
CPUQuota=50%
MemoryMax=512M

Provide controlled writable directories Set ReadWritePaths= ReadOnlyPaths= to control filesystem access. This will make service only read/ write specifed directory.

Example:

[Service]
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Drop dangerous privileges

Set CapabilityBoundingSet= to drop dangerous privileges.
This will make service only able to run commands with specific privileges.

Example:

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Run temporary / ephemeral services Set RuntimeDirectory= StateDirectory= LogsDirectory= to run temporary / ephemeral services. This will run the service in a temporary / ephemeral directory.

Example:

[Service]
RuntimeDirectory=myapp
StateDirectory=myapp
LogsDirectory=myapp

Limit process / thread count Set TasksMax= to limit process / thread count. This will make service only able to run with specific process / thread count.

Example:

[Service]
TasksMax=100

Restrict access to system calls Set SystemCallFilter= SystemCallArchitectures= to restrict access to system calls. This will make service only able to use specific system calls.

Example:

[Service]
SystemCallFilter=open,read,write,close
SystemCallArchitectures=amd64

Security measures for Docker Engine Set Delegate=yes to run Docker Engine with specific privileges. This will make Docker Engine only able to run with specific privileges.

Example:

[Service]
Delegate=yes

Conclusion

We could able to use systemd.exec options to secure application running in systemd.

But Until we integrate with real application and test these options, we can't be sure about the security.

In the next article we will see how service react with integrations of these options.

Reference Man Page Systemd : https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc