Export it out as jsxbin, you can do that using Extendscript toolkit. To add another layer of security over it, you can use jsxblind library by Marc. See the details below
Some scripting languages (e.g. AppleScript) can save scripts in binary (bytecode) format, which requires specialist knowledge to convert back to human-readable code, and some (e.g. Python) have tools that can convert your scripts to C code and compile that, which would take a very skilled programmer a lot of time to reverse. Or you’ve always got the option of implementing your product as a C++ plugin, which again is a lot more expensive for others to reverse-engineer—and a lot more expensive for you to write in the first place.
That said, even programs written in fully compiled languages such as C++ and distributed in binary form only (e.g. Adobe Illustrator) aren’t immune to reverse engineering given sufficiently skilled and motivated programmers of dubious morals. (Hence all the w*r*z sites offering “cracked” versions of commercial software.)
It’s all a matter of weighing costs vs benefits. Your hope is that the time and labor (and possibly legal) costs to them of hacking your code significantly outweigh any benefits they might hope to gain, and so deter them from doing so. If it’s a simple low-cost script you wrote for a handful of clients then running through an obfuscator is likely sufficient to put them off trying to extract your “secret formula” and just pay their fair dues to use it. OTOH, if it’s a major software product that’s going to retail globally and generate millions of dollars a year then, yeah, someone’s likely going to crack that code. But that’s why you have copyright, software licenses, legally-binding contracts, and your own fleet of well-paid lawyers so you can go after those violators with the law.
p.s. Encryption isn’t really a practical solution as your customers’ computers need to be able to run your software themselves—which they can’t do if it’s been locked with encryption and only you have the key. So even if you do encrypt your main code, you still have to supply a way to decrypt it along with the key for performing that decryption… and you’re right back to where you were to begin with. Again, if you’re thinking on those lines you’ll be much better investing in a big bucket of chum for your legal department.
p.p.s. Were you doing high-end InDesign automation, you’d have another option which is to offer your automation as a hosted service (aka “SaaS”) where users upload their source files to your website which automates them using InDesign Server and returns them the finished files. That way users never have access to your proprietary automation code so cannot steal it (short of breaking into your server and/or data center and committing outright theft). But of course you have to consider if that operating model works for both them and you (and unless it’s earning you six-figure sums the costs of licensing IDS alone mean it’s not worth your trouble). That’s not an option with Illustrator though, which only allows existing license-holders within your own organization to use it.