I wrote a terse article last year about the fact that no one should ever need to be in CRXDE in Production. And they shouldn’t be! I kinda skated over another fact related to this that I want to address. You shouldn’t be on your Publish server, especially not in Production.
As Tyler mentioned in his article series about the entire Adobe Experience Manager infrastructure, “the Publish server is the workhorse”. It shares a similar setup to the Author server, as it also runs as a Java application. Most of the information about setup and startup that were done to the Author server also applies to the Publish server (including using the same jar file). You just use the installation run mode of “publish” and the default port changes as well.
The difference is that Publish is responsible for rendering all the content that is meant for consumption by the front-end user. As Tyler said, “it is a render host”. The nature of the Publish server is to handle serving up content and markup for caching to the Dispatcher. It takes all that and generates static data that is delivered to the browser. The Author server is where you input content using the tools, components, and templates that developers build. But until they hit that Publish (activate) button it is just staged content. Its job is to communicate between the Author and the Dispatcher, not to do actual authoring or configuration.
One of the reasons you shouldn’t be on the Publish server is server consistency. Most likely you will have more than one Publish server. The concern is that if someone were to go to one of the Publish servers to make an adjustment to the code, content, or configuration, they might forget to make that adjustment to the remaining servers as well. If you make whatever change is needed on Author and then replicate it, then all the Publish servers stay consistent. It’s not tenable for someone to have to hit each publish instance to make whatever change they need. You are ignoring the way that AEM was designed in the first place.
Another reason to avoid this is from a scaling perspective. Having all the logic, configurations, code, and content live on the Author server ensures that, when you scale up, everything gets replicated out to the Publish server. So as long as you have your replication properly set up you won’t have to worry about making those changes to a new Publish server, you can just replicate it from Author again. Without that, you have no guarantee.
Lastly, I know it sounds pessimistic, but if you are making changes directly on a server, rather than in a repo, there is a high probability that you are going to forget to get it into your repo. Then the next time you deploy your code it will get overridden and you will be left wondering why something is broken that was working before—all because you wanted to make a “quick fix”.
Someone might whine and say, “but something is wrong and this will be faster, just let me make this small change”. I would argue that your real problem is that something is not configured correctly or you have a blocked replication queue and that your real problem is how Author is communicating with Publish. Getting on the Publish server only resolves a symptom and isn’t the cure. Don’t make your implementation of Adobe Experience Manager dependent on people needing to access the Publish server. Don’t do it!