so two options here -

• I get the team involved and they manually switch your service to nixpacks

• you simply deploy your code into a new service and that will automatically use nixpacks

Will it be too much hassle to involve the team? I would like to keep the same project id, and logs for the project history

hassle? no not really, i see this as user-solvable and if we can solve this together its going to be faster than getting the team involved.

the second option doesn't involve a new project. just a new service

trying the second option

can you run your action plan by me first?

i dont want you to do something that you didnt mean to

sure

1. Create a new service with same config, source, and env vars as the current one.

2. Make sure everything works as expected.

3. Rename the public urls of current one to [service-url]-deprecate

4. Rename the public urls of the new service to [service-url]

I am not using other services directly within this one, or communicating internally to the current service. So the service id change will not impact that much on what im attempting to do

Please let me know if the above sounds right

as long as the service you create is within the same project you are good to go

thanks

question before making the final change. Will the previous domain used on old service will be available to use on the new service right away?

yes the domain would be available to use on a new service right after being removed from the old service

Wanted to confirm the service is working.

awesome