In specific cases, using app-level authentication can prevent deployment from executing properly. This usually happens when a user with limited privileges is used as default-user for (one of) the app-servers. This most often happens when people use the built-in REST-api together with app-level authentication. We typically advice against this, but in case you insist on the approach one of the few options you have is to flip app-level auth off and on during deployment. You could potentially put something like the following in your deploy/app_specific.rb:

 alias_method :original_deploy_rest, :deploy_rest def deploy_rest if @properties["ml.authentication-method"] == "application-level" change_authentication("digestbasic") end original_deploy_rest if @properties["ml.authentication-method"] == "application-level" change_authentication(@properties["ml.authentication-method"]) end end def change_authentication(auth) r = execute_query %Q{  xquery version "1.0-ml";  import module namespace admin = "http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy";  let $config := admin:get-configuration()  let $config := admin:appserver-set-authentication($config, xdmp:server("#{@properties["ml.app-name"]}"), "#{auth}")  return  admin:save-configuration-without-restart($config)  } r.body = parse_body r.body logger.info r.body logger.info "Changed authentication to #{auth}.." end

Note: in case you make use of the ability to use XCC communication over an HTTP app-server (xcc-port=${app-port} with install-xcc=false), you need to flip back and forth authentication for both deploy_src and deploy_rest, and potentially even for deploy_schemas. In that case it might be easier to not reuse the HTTP app-server, and allow Roxy to create a separate XDBC app-server.