Where does a protection step even go on a low-code platform?
Wherever you own a build, and nowhere else. These platforms split into two halves and the halves behave completely differently. Managed source is code you paste or commit into the vendor's editor: the platform parses it, transpiles it, bundles it and serves it, and there is no point in that chain where your artifact exists for you to transform. Uploaded artifacts are the other half, where you run your own build locally and upload the result as a static resource, a packaged control or a custom module. That second half is a normal build pipeline and takes a protection step exactly like any other. The first question to answer about your own project is which half each piece of your code lives in, because the answer decides what is possible before any option matters.
Why does member renaming break a low-code component so badly?
Because the framework calls your code by name, and those names are a contract rather than an implementation detail. A component model invokes lifecycle methods it expects to find, a template binds to property names it reads from your class, a platform action dispatches to a handler whose name is declared in metadata somewhere outside the file. Member renaming rewrites property access, so a blanket setting renames one side of that contract and leaves the other side pointing at a name that no longer exists. Nothing errors at build time and nothing errors at parse time. The component mounts, the panel draws, and one region quietly does nothing. Use the rule-based member selection and keep every framework-facing name out of scope.
Is my platform code even exposed? It sits behind a login.
It is exposed to everyone who can log in, which is a different and usually larger group than you first picture. An internal application is readable by every licensed user in the org, every contractor with a seat, every partner in a community or portal, and anyone who has kept a session from a role they no longer hold. That is the insider and partner threat model rather than the open-web one, and it is the honest reason to protect this code: not because a stranger will find it, but because the person reading it is already inside and is looking at the logic that decides approvals, limits, pricing or eligibility. Authentication changes who reads your bundle. It does not change that they can.
Does the domain lock work on a tenant hostname?
It works, but it is high maintenance here in a way it is not elsewhere, and the maintenance falls on a schedule you do not set. The guard reads the browser's hostname and compares it against your allowlist. On a hosted platform that hostname is assigned by the vendor, differs between production and every sandbox, and changes when a sandbox is refreshed or an org is migrated. So a lock that is correct on Monday fails after a refresh nobody told you about, and the failure lands on users rather than on a build. If you use it, include every sandbox pattern deliberately, keep the list next to whatever document records your org topology, and choose a failure action that degrades rather than one that throws.
Which runtime defenses can I actually use inside a platform runtime?
Fewer than the option list suggests, and the build tells you which. Three of them, the self-defending wrapper, the self-healing recovery wrapper and the anti-tampering monitor, evaluate code at run time, and the engine emits a warning that they need a policy permitting dynamic evaluation. Platform runtimes commonly enforce a strict content security policy, which is exactly the policy that forbids it. Those same three are also skipped automatically when the source is an ES module, with their own warning, because they are classic-script wrappers that would break import linking. Modern component models are ES modules, so on a lot of low-code work those options were never applied even where the policy would have allowed them. Read the build warnings instead of assuming the setting took effect.
What about blocking the console or developer tools on an internal app?
Both are worse choices here than almost anywhere else on this site. Emptying the console methods removes the one diagnostic channel an internal user can send you, and internal users are the population most likely to be asked for a screenshot of an error. Blocking keyboard shortcuts and the context menu cancels events inside an application whose shell belongs to the vendor, which interferes with platform affordances and with assistive technology, and it does nothing about a bundle that has already been downloaded. Neither option prevents reading. Both cost you support time from colleagues.
How do we keep platform metadata and our build in agreement?
By treating every externally declared identifier as an exclusion and reviewing the list whenever the metadata changes. Low-code platforms keep a lot of your program outside your source: handler names in a flow definition, field and object API names, action identifiers, event names, component attributes declared in a configuration file. All of those are matched as text by something you do not control. Put the names in the reserved-name configuration so renaming leaves them alone, put any literal the platform matches on into the reserved-strings configuration so the string transforms leave it alone, and keep both lists in the same review as the metadata rather than in a build file nobody opens.
Is it worth protecting an ISV package we distribute to other orgs?
That is the case with the strongest argument on this page, because it is the one where your code leaves your own tenancy. A packaged component installed into somebody else's org is a published artifact in every practical sense: the subscriber can read it, and so can anyone they grant access to. Protection raises the cost of lifting your implementation into a competing package, and a watermark lets you attribute a copy you find later to the build it came from. Pin a seed as well, so the diff between two releases shows the change you made rather than a total rewrite, which matters when a subscriber or a platform review looks at an upgrade.
Will the platform reject or re-process protected code?
It may do either, and the only reliable answer comes from your own vendor rather than from us, so confirm it before you build a release process on top of protection. What is consistent everywhere is the mechanism. Platforms of this kind commonly lint, statically analyze, transpile or re-minify what you give them, and any of those steps reads your code. Heavily transformed output is harder for a static analyzer to interpret and resembles the shape that security tooling is trained to flag, and a re-processing step applied after your protection step can undo part of it or fail on it. Test the round trip on a real deployment rather than assuming your artifact arrives byte for byte.
What is a sensible order of operations for a release?
Five steps. First, split your inventory into managed source and uploaded artifacts, because only the second half can be protected at all. Second, write down every name the platform reaches into your code by, from lifecycle hooks to metadata-declared handlers, and turn that list into your exclusion configuration. Third, run every tool that works by reading code, including composition analysis and secret scanning, against the artifact before it is transformed. Fourth, protect with a fixed seed and deploy to a sandbox, then exercise the paths that touch platform APIs rather than only loading the page. Fifth, keep the symbol map and the build manifest for the exact deployed version, because a defect report from an internal user of a protected component is otherwise close to undebuggable.