When Framework deploys a pre-prepared package (via sls deploy --package pakage/path.zip), the service in which context its run is irrelevant, all configuration for service in current working directory is ignored.

Still we're not capable to run sls deploy --package pakage/path.zip when not being in service context, that seems as a design bug.

It's unfortunately not trivial to achieve with current complex internals flow. #8499 is scheduled to tackle this and other related problems

Original report:

With the new package/deploy commands, the build and deploy steps can be distributed in a CI/CD system and be executed on different servers by just specifying the path to the built package on the deploy side.

However, there is still a small improvement possible in the workflow.
Currently Serverless needs a valid serverless.yml in the root of the service to be able to start. The build server has to add it (including the yml dependencies/includes) to its emitted artifact together with the built package.

For the package command, the service state is integrated into the package output and the deploy command resumes its operation on the package without the need to access any local service definitions (yamls). So the transfer of the service yaml could be removed completely if serverless could start without it.

There should be a bootstrapped start of the serverless binary that is enabled for the deploy command (in case it find a --package option). This start mode should bypass the serverless.yml checks and just start the deploy command, which will instantiate the current state from the package output.

From an implementation side, it would be easy to implement something, that commands could be extended by some flags array (as siblings to the lifecycleEvents array). These flags could specify some special behavior that is triggered or activated for the commands. A missing flags array would keep the current behavior (load the serverless.yml and call the command). The flags would only be available for core plugins because of the proposed bootstrap semantics mentioned below.

Example:

...
this.commands = {
  deploy: {
    lifecycleEvents: [ ... ],
    flags: {
      bootstrap: this.shouldBootstrap()
    }
  }
}
...
shouldBootstrap() {
  return this.options.package;
}

When serverless now initializes, it should first load the core commands and core hooks, check if the called command wants a bootstrapped mode (if (command.flags.bootstrap) ...) and either continue with loading the serverless.yml or immediately execute the command.
The package command and the deploy command (in bootstrapped mode) should additionally persist plugins used during the build stage and load them on its state restore, to have needed plugins active on separated package deployment. All the functionality is already present in pluginManager...

My estimation is, that these changes can be done with minimal efforts - besides the needed new unit tests for the bootstrapped mode.