Microsoft Access Databases Deployment Options and Compiled, Protected .ACCDE or .ACCDR Files (Tutorial)
Learn about the different options for deploying your Microsoft Access 2016 databases to end-users, with pros and cons outlined and links to relevant tutorials.
Deploying a "Compiled" Protected .ACCDE File
If you are interested in protecting your database from editing with designers or hiding some of those options, you can "compile" your database to an .ACCDE (.accDE not .accDB) file via File > Save Database As > Make ACCDE.
You can also distribute the Microsoft Access Runtime to end-users IF they don't already have Microsoft Access installed.
Checkout this excellent tutorial on how to create a compiled ACCDE (non-code-editable) database file.
Though it won't by itself simplify deployment, it will (somewhat) protect your VBA code from being viewed or somethings from being edited and may help performance a bit. However, if you're not working about users editing tables and report layouts (or want to allow that) or editing or seeing the VBA macros, then you can just distribute the .ACCDB file directly.
Showing Form on Startup and Hiding Design Tools
You can set a Display Form to automatically open on startup when the database is opened by selecting or entering the name of the form at File > Options > Current Database > Application Options > Display Form.
You can also use the options there to hide the Navigation Sidebar, Default Ribbon (Copy, Paste, Refresh All, Database Tools, etc) and/or Right-click Context Menu (Copy, Paste, Sort A to Z, Text Filters etc.) to simplify the UI for your user.
You can also define a custom Ribbon menu bar as seen in this Custom Ribbon Bar tutorial.
Renaming to .ACCDR for Runtime Mode
Also, you can rename an .ACCDB file to .ACCDR file to have it launch in "Access Runtime only" mode, hiding the Microsoft Access design tools and default Ribbon (Copy, Paste, VBA, etc.) menu tabs and buttons, as detailed in this ACCDR tutorial.
Distributing Access Runtime to Users without Access Installed
You can then, if desired, download the Microsoft Access 2016 Runtime (or version that corresponds to your version of Access) for users who don't have Microsoft Access installed to use, such as is available from here:
Then distribute that to your end-users for one-time install so can run your .accde files (works with .accdb too if don't care about compiling). However, the main Access ribbon and right-click context menus won't be available and there are a few other restrictions when the Runtime is installed instead of the full version of Microsoft Access.
Windows .MSI Installer Creation
You could use WIX or free or commercial installer builder to install that runtime as a dependency and install your database to certain file path, but may be more trouble than it's worth.
You could also just use 7-zip to create a Self-Extracting .exe that will run runtime installer (or run it followed by your database, eg. by having it run a batch file).
But usually just one-time manual Runtime install followed by using all your .accde files is simplest.
Alternatives with Previous Access Versions
When deploying Microsoft Access 2016 databases to end-users, I suggest compiling to ACCDE and, if needed, providing end-users with Microsoft Access Runtime, as detailed here:
However, there are a few alternatives for previous versions that have their own pro's and con's, detailed here.
For Access 2010, you could create an .msi Windows Installer package from your database which bundled Microsoft Access Runtime with it for automatic install.
Access Database MSI Installer Tutorial
However, Windows Installer Packaging was deprecated since Access 2013 (as Microsoft was suggesting deploy as Access Web App instead).
Digital Signing Options
Now with Access Web Apps also dead, all that's left over from packaging is Save Database Access > Package and Sign > to save to .accdc signed file.
As mentioned here, that doesn't help deploy, just places complex restrictions requiring a certificate to package or covered in this Access Signing Documentation.
If you wanted to do that (not suggested), you would need to buy a developers signing certificate from DigiCert etc., as described in Getting a Certificate documentation.
Therefore, for Microsoft Access 2016 users - or 2013 users who have moved away from Access Web Apps now that they are deprecated, in most cases, you may just wish to compile your package to an .accde file to deploy.